[Owasp-leaders] Is it ok to share the PGP Keys and keep the PassPhrase private?
dinis.cruz at owasp.org
Thu Oct 14 16:57:34 EDT 2010
Hi Rogan, great comments
On 14 October 2010 10:56, Rogan Dawes <rogan at dawes.za.net> wrote:
> > My assumption is that: *"as long as the PassPhrase is strong enough, it
> > would be not practical to brute force it (even if the attacker knows the
> > Private Key)"*. In fact, should the question be: *"How big does the
> > PassPhrase be in 2010/2011 time frame for it to be secure?"*
> Well, what size PGP keys are you generating? The passphrase should be
> that big . . . :-)
That is part of my thinking, surely in a PrivateKey + PassPhrase model
aren't both elements important? For example would it be OK to keep the
PrivateKey private but share the PassPhrase?
But actually, are they equally important (the Private Key vs PassPhrase)? in
the SecuritTeam blog there was a comment that said that multiple PassPhrases
could be used on the same PrivateKey (and maybe one could be discoverable
via an Oracle Padding attack and the other not?).
> Ok, non-flippant answer:
> It seems to me that the answer depends on exactly what you are trying to
> achieve. If you want to implement passphrase-based encryption, that uses
> a standards-based protocol for compatibility reasons (e.g. excluding
> encrypted ZIP archives), generating and distributing both private and
> public parts is reasonable.
And that was one of my original use-cases (to replace encrypted zip).
Basically I needed to send a bunch of O2 Scripts + Customer data to a client
and it was too big to send by email, so I wanted to put it on Amazon S3 and
send the link to the customer.
Now, I didn't want to use encrypted ZIP and since O2 already had the
capabilities (via the BouncyCastle API) to easy handle PGP, I thought that
it could be an interesting alternative.
So maybe the question should be *"by exposing the public and private key (to
somebody sniffing the Amazon S3 traffic when the client downloaded that
data) but keeping the PassPhase private, is that solution AS GOOD as
using Symmetric encryption?"*
> Of course, the security is then only as good as the passphrase is (but
> that's still the same as if you were using passworded ZIP), so . . .
Yes, and I was trying to figure out, how big it should be? For example as
you can see on the O2 Script that powers this
using the 21 char (with UpperCase and 1 non-printed char)
Is that big enough? How long would it take to brute force that?
> If you want top level security, then you should not be distributing the
> private keys, unless the passphrase has a similar bitstrength/keylength
> as the keys themselves. The user could always change the password to
> something more usable once it has been received. I seem to recall
> estimates of 3 bits per English word, fwiw.
The core idea here is to start using some type of encryption and gain the
behaviour culture to do so. For example we can argue that the private key
should be private, but how do I security give it to the client in a 1x way
transaction? (i.e. not using normal PGP key exchange where the client gives
me first his private key)
I guess what I'm really after here is to simplify the use of encryption
technologies like PGP, since at the moment its (PGP) adoption is very ,
very, very low. For example how many products today natively suport
PGP? (lets say in storing its results and loading data). And how many
security consultants/teams regularly use PGP to communicate with clients (or
internally) and use it consistently across the board to protect all
sensitive data that they have access to?
And before we get too precious on the need for the Private Key to be
private, securely handling private keys is a MASSIVE challenge (if one wants
to do it properly). Ironically, having the PassPhrase as the 'key-holder'
might turn out a better model since it will be easier to protect/distribute
that PassPhrase than it would be to protect/distribute the private key :)
I've been thinking about his issue, and I think I have found a
couple scenarios where my original idea could be interesting :) (I'll write
it up next)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders