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

Neil Matatall neil at owasp.org
Fri Oct 15 12:00:30 EDT 2010


>
>  The resulting discussion has taken the "what color to paint the bike shed"


I would like to sit in on any calls related to the matter, it sounds like a
conference call is needed.

On Fri, Oct 15, 2010 at 8:17 AM, Rory McCune <rorym at nmrconsult.net> wrote:

> 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
> well...
>
>
> cheers
>
> rory
>
> 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
> >
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>



-- 

--

Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/d01fe71f/attachment-0001.html 


More information about the OWASP-Leaders mailing list