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

dinis cruz dinis.cruz at owasp.org
Fri Oct 15 03:55:08 EDT 2010


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). 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)).

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)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/030dfc02/attachment.html 


More information about the OWASP-Leaders mailing list