Focus on Microsoft
Announcing TGP - Thor's Godly Privacy Jul 09 2010 06:55PM
Thor (Hammer of God) (thor hammerofgod com) (1 replies)
Re: Announcing TGP - Thor's Godly Privacy Jul 10 2010 05:36PM
Jeffrey Walton (noloader gmail com) (1 replies)
RE: Announcing TGP - Thor's Godly Privacy Jul 10 2010 06:37PM
Thor (Hammer of God) (thor hammerofgod com) (1 replies)
Re: Announcing TGP - Thor's Godly Privacy Jul 13 2010 02:40AM
Jeffrey Walton (noloader gmail com) (1 replies)
RE: Announcing TGP - Thor's Godly Privacy Jul 13 2010 05:26AM
Thor (Hammer of God) (thor hammerofgod com) (1 replies)
>> First off, no, I'm not leasing or selling any code. It's all free As
>> such, it's not "sales literature," but just an info page.
>My bad. I meant 'releasing' I'm not sure what happened to the 're'.
>And sorry you missed the humor....

Ah - with the "lease" and "sales" I didn't catch that ;) Actually, no, I'm not going to release the code. It is interesting that you bring that up though. I just had a discussion today with the Bugtraq moderator about that. Bugtraq no longer will announce tools unless they are open source. That's totally fine, but I think it brings up a very interesting point about what open source is, and isn't, and what value there is in providing source.

Personally, I think providing the source for a program like TGP makes it less secure. The reason for this is that if I post the source, anyone can recompile it with Trojan options, distribute it, and no one would know. I mean, it's .NET - so even if I did post the source, you really don't know if the calls I make are "real" ones from the source alone. While the source may make it easier for you to see how I implement TGP, you can really just do that on your own if you wish... It's all tried and true cryptographic standards that can be independently verified with any other utility that supports SHA256, AES256, and RSA. Logic dictates that if one is capable of verifying an implementation by source code audit, then one is capable of writing it on their own. But people don't really do that in real life - the let other people (like me) write stuff and throw it out there and people trust them not to do something unethical.

People need to remember that posting source code was NOT originally so you could see if something was secure or implemented correctly. It was so that you could compile it yourself when you had environmental dependencies of your own. And you don't know if I post the "real" source code or not. You have to trust me, or audit the binaries. If you are going to audit the binaries, then you don't really need the source.

I know there are as many valid reasons for closed source as there are against. But it all comes down to what the author chooses to do, and for now, I choose not to disclose the source...

>>>> ... the Dropbox parsing function actually validates the data, checks
>>>> the hash, and creates a new file for you.
>I'm still not clear on the hash, where it resides, and how it's used.

The hash is nothing more than a SHA256 hash of the keys. If I send you a fob file, you'll know it's not been tampered with because of the hash. I'm not worried about extension attacks on SHA256 right now. Maybe I should be... I guess I'll build in SHA512 and downward compatibility with SHA256 later. I generate the keys, export them to XML, and hash the contents for integrity checks. My whole point about HMAC is that it won't help for authentication, meaning, I'm the one who really made the keys and not someone pretending to be me when you finally get a copy of my public key.

>> You don't need a keyed hash for integrity,
>Integrity alone is usually meaningless due to the vacuum. If you can compute
>it, so can the bad guy. If its work integrity checking, it should be MAC'd.

Fair enough - I'll follow up below:

>> That's the hash of the key. If you change the key, the hash won't
>> match. If you change the hash, it won't match the key.
>What about extension attacks? That's why hashes lost favor.

That's covered above... Maybe I should think a bit more about better-validating the hash, but I'm still not convinced it is necessary for this use case.

thx

>
>Jeff
>
>On Sat, Jul 10, 2010 at 2:37 PM, Thor (Hammer of God)
><thor (at) hammerofgod (dot) com [email concealed]> wrote:
>> Hey Jeffery -
>>
>>>Will you be leasing source so the implementation can be verified? I'm
>>>interested in the security levels of the components, and its hard to gather
>>>from the sales literature. I don't believe it was listed at
>>>http://www.hammerofgod.com/tgp.html. More from that page....
>>
>> First off, no, I'm not leasing or selling any code.  It's all free.  As such, it's not
>"sales literature," but just an info page.
>>
>> That being said, I should go ahead and put up something about the
>implementation.  It is all standard MSFT .NET cryptographic libraries, using RSA
>and AES cryptographic libraries.
>>
>> Others in line:
>>
>>>> Key DropBox
>>>>
>>>> If you get someone's private key off the internet or via email, 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.
>>>Hmmm.... someone else's private key? Perhaps you will take the liberty of
>>>signing for some one else, which seems to nullify non-repudiation.
>>>If you're looking to read someone else's confidential data, perhaps you
>should
>>>use Samir's Secret Sharing scheme. Then, all interested parties can access
>the
>>>data.
>>
>> Totally.  That should be "public key."  I just changed it on the site.   I must
>have still been on the "posting your encrypted private key fob" bit (which an
>interesting bit by itself).  The drop-box function is only for public keys.  I really
>only made that because I found the first you do with the key-fob XML file is to
>open it in IE, which automatically expands XML for you, thus putting in the
>little "-" sign in front of elements.  I wanted to be able to still copy and paste
>even from IE.  The feature itself is actually not all that valuable otherwise.  I
>am, however, adding the same functionality to decrypting data - just drop it in
>and decrypt.  At that point it will be a more valuable function.
>>
>>>> ... the Dropbox parsing function actually validates the data, checks
>>>> the hash, and creates a new file for you.
>>>One cannot make any integrity or authenticity claims when using an
>unkeyed
>>>hash. If you can calculate the hash, so can the bad guy.
>>>Perhaps you should use a MAC such as HMAC (HMAC is a keyed hash).
>Then
>>>you can make a integrity/authenticity claim.
>>
>> You don't need a keyed hash for integrity, only authenticity.  That's the hash
>of the key.  If you change the key, the hash won't match.  If you change the
>hash, it won't match the key.  That's an integrity check.  Using an HMAC
>presumes one know the "secret key" you hash with in order to validate what
>is being called "authenticity."   Without it, it is of no value.   A keyed hash is
>only going to be valid to prove authenticity if you use an additional element of
>PKI where the issuer's signature can be validated or some other method to
>share the "private key" used to hash the key.
>>
>> Self-generated public keys can't be authenticated in any meaningful way
>other than validation between 2 parties.  If you are worried about the "bad
>guy" changing the key and the hash then he'll just change the signature as
>well.  Actually, he won't have to change anything - he'll just generate his own
>and replace it.  That's why you have the hash and the key - to validate
>integrity.  If you don't trust were the key came from, you can validate it offline
>before you use it to encrypt for the recipient.  That's how the whole self-
>generated key scheme works, and which is why I built PKI support for x509
>into v1.2  - for those in a position where they cannot trust where the key
>came from, and where they cannot validate the key in a separate
>transaction.   That being said, when we have to worry about SHA256 collisions
>to the point that you can create 2 different valid public RSA keys that have the
>same hash, I'll probably just move to SHA512 instead of trying to fix an
>authentication issue that really can't be fixed with self-generated keys.  At
>some point, you've got to just say, "here's the key."  If I use a key to validate
>another key, then I'd have to use another key to validate the key I used to
>validate the first key.   That's the inherent issue with self-generation... after a
>while you start feeling like you are in a roundabout in Mississippi.
>>
>> t
>>

[ reply ]
Re: Announcing TGP - Thor's Godly Privacy Jul 13 2010 11:17PM
Phillip Macey (phillip macey cisra canon com au) (2 replies)
RE: Announcing TGP - Thor's Godly Privacy Jul 16 2010 04:26PM
Wayne Anderson (wfrazee wynweb net)
RE: Announcing TGP - Thor's Godly Privacy Jul 14 2010 12:23AM
Thor (Hammer of God) (thor hammerofgod com)


 

Privacy Statement
Copyright 2010, SecurityFocus