[Owasp-leaders] Is it ok to share the PGP Keys and keep the PassPhrase private?

Rory McCune rorym at nmrconsult.net
Fri Oct 15 07:24:22 EDT 2010


some more comments in-line

On Fri, Oct 15, 2010 at 8:55 AM, dinis cruz <dinis.cruz at owasp.org> wrote:
> Comments inline
> On 14 October 2010 11:09, Rory McCune <rorym at nmrconsult.net> wrote:
>>
>> On Thu, Oct 14, 2010 at 10:38 AM, dinis cruz <dinis.cruz at owasp.org> wrote:
>> If you're essentially relying on the security of the passphrase to
>> provide the confidentiality check, wouldn't it just be easiest to use
>> a symmetric crypto algorithm (eg, AES)?.  IIRC from Prof Pipers talk
>> in Dublin the problem that public/private key crypto was designed to
>> solve was the secure distribution of the keys, so as you're not using
>> that side of things (by relying on out of band passphrase ), there's
>> no real need to use PGP :)
>
> So here is where things start to get interresting. For example I quite like
> the idea that with the proposed model there is a case where anybody (or any
> tool) can encrypt the data, but only one player (the one with the password)
> can decrypt it.
>
> When you compare it with Symmetric encryption (where all players can encrypt
> and decrypt (players = 'access to the key(s)' ) I think there are some
> interresing use cases (see below)
>
>>
>> Also thinking about it the PGP solution could be somewhat less
>> flexible than the symmetric crypto solution.  If you want to change
>> the encryption key with PGP you're going to need to redistribute new
>> keys and presumably change/distribute the passphrase in use,
>
> Actualy no, I could redistrubute the Keys and keep the same PassPhrase
> (since that is something that only me and the receipient knows).

You could do that, but given that the passphrase is likely to be the
weakest part of the chain (eg, key length less than the private key)
re-issuing a new key with the same passphrase probably isn't getting
you much benefit. (assuming here that they "private" key is assumed to
be known and the only secret in the chain is the passphrase.

Depends on use cases for whether you see changing the keys as
necessary.  if there's no real need for changing or rotation of
secrets then it's not an issue.

For
> example, with O2, I'm going down the route of creating custom O2 versions
> per client (or subscriber), so I could have a model when I share a
> PassPhrase with the Custom O2 user(s) and then (if required) freely change
> the keys on new versions (with the idea that I would use PGP to encrypt some
> of that Custom O2 module (for example the client-specific scripts/APIs)).

See above but if you're assuming that the passphrase/key have been
compromised (which a main reason to change them) then re-transmitting
a private key over an untrusted channel where it has the same
passphrase, really doesn't solve your problem, as a hypothetical
attacker already has that passphrase.

For the use case your looking at above, would another option be, to
provide the functionality in O2 for the user to generate a
public/private key pair and then have the public key sent to you as
part of the registration process.  That way you get away from the
problem of passing the private key over the network...

>
> One of the usability items that I think is very relevant is that it is
> easier to exchange PassPhrases with users, than it is to exchange a Private
> Key (again assuming non-normal PKI interactions and one-to-many distribution
> models (i.e. there are multiple users that need to be exposed to the Keys))
>
>>
>> whereas
>> with a symmetric solution, you just change the passphrase in use and
>> distribute it.
>
> Yes and as with Symmetric encryption, I like the concept that there is only
> one secret between me and the user/client (i.e. a PassPhrase (or maybe call
> it password)). I also like the fact that I'm not making the life harder for
> my users by creating an asset (Private Key) that they need to manage.
>
> Going back to the idea I mentioned above. I'm really starting to like the
> model of "having the ability to easy encrypt data (using the Public Key) and
> the limited ability to decrypt it (using the PrivateKey + PassPhrase)"
>
> Here are a couple examples:
>
> Tool XYZ encrypts all data it creates (namely all findings) but can't read
> it back (good way to help the distrution of that data)
> Developer uses the Public Key to encrypt some of its artifacts (like source
> code) for distribution to security consultants
> Security consultants encrypt its report(s) using the exposed Keys (this
> would be useful during the engagement and for the final report)

yeah I've seen this kind of idea suggested for logging sensitive data
on web tiers.  So you can log things like CC numbers, encrypt them
with a "public key" and ensure that the private key is held on a
completely separate machine/network, so that an attacker compromising
the web server doesn't automatically get access to that data (well at
least from the logs anyway)

>
> NOW I know that if one can do proper PKI (public key exchanges) it would be
> a more robust workflow, BUT I like the simplicity and the usabiliy of it.
>
> Remember that today, encryption is barely used, so in my book if this
> concept increases the amount of encrypted data, then surely that is an
> improvement.
>
> Finally, the idea of 'sharing' secrets is very common is Desktop/Client-Side
> apps, and is something that is already happining on security features like
> OAuth (see how I had to include the OAUTH_CONSUMER_KEY and
> OAUTH_CONSUMER_SECRET in O2's source code in order to the the Twitter API to
> work :
> http://code.google.com/p/o2platform/source/browse/trunk/O2_Scripts/APIs/Twitter/O2TwitterAPI.cs)
>
> Dinis Cruz
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>


More information about the OWASP-Leaders mailing list