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

Rory McCune rorym at nmrconsult.net
Fri Oct 15 11:17:22 EDT 2010

yeah it's friday afternoon (well in this jurisdiction anyway :)

personally I like straight PGP public private key crypto for most
things.  It's v. easily cross-platform, free (gpg) and once the
initial key setup is done, reasonably straight forward :)  The problem
is usually for large or non-technical userbases, it just doesn't (IME)
work too well.  For distributing info generally, quite a few companies
I've seen use PGP's web messenger product which seems to work pretty



On Fri, Oct 15, 2010 at 4:08 PM, James McGovern <JMcGovern at virtusa.com> wrote:
> Who can refuse getting sucked into arguments regarding the correlation between the price of tea in china versus how many cross-site scripting vulnerabilities exist in the latest toaster on sale at Wal-Mart?
> I still think using an IBE approach is the best answer where the style is less about PKI and having to protect keys. Built into IBE is the ability for keys to change based on policy without parties having to go through arduous key exchange ceremonies while still maintaining whatever they feel for doing passphrase work.
> James McGovern
> Insurance SBU
> Virtusa Corporation
> 100 Northfield Drive, Suite 305 | Windsor, CT | 06095
> Phone:  860 688 9900 Ext:  1037 | Facsimile:  860 688 2890
> -----Original Message-----
> From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Rory McCune
> Sent: Friday, October 15, 2010 7:24 AM
> To: owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Is it ok to share the PGP Keys and keep the PassPhrase private?
> 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
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> Virtusa was recently ranked and featured in 2010 Global Services 100, IAOP's 2010 Global Outsourcing 100 sub-list, 2009 Deloitte Technology Fast 500 and 2009 Dataquest-IDC Best Employers Survey among others.
> ---------------------------------------------------------------------------------------------
> This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is intended for the addressee only. Any unauthorized disclosure, use, dissemination, copying, or distribution of this message or any of its attachments or the information contained in this e-mail, or the taking of any action based on it, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this message.
> ---------------------------------------------------------------------------------------------
> _______________________________________________
> 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