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

Matthew Chalmers matthew.chalmers at owasp.org
Fri Oct 15 15:56:12 EDT 2010


Let's make the assumption that Dinis has a business requirement to use the
proposed (compromised) design. We live in the real world, not a perfect
world where we can always pick perfect solutions. ID-based encryption relies
on a trusted third party, which is not part of Dinis's design, but I don't
like the looks of this "O2" tool (which I've never heard of) because it
shows passphrases in the clear and has a checkbox for "store in config file"
which scares me. But that's besides the point.

Dinis basically wants to be able to inform his customer how secure the
proposed design will be (i.e. how long should a private key with a
passphrase of a given length/composition be expected to survive
unprotected). That is, how much compromise is involved.

Unfortunately we aren't told how the private key will be exported and
"published" (and I don't really have time to fully analyze the O2 tool). I
believe PGP's default is to export in PKCS#12 using PKCS#5 password-based
encryption. You can see details of how the key is derived from the password
and what algorithms are used here: http://www.ietf.org/rfc/rfc2898.txt.

Suffice it to say, there are a lot of ways an application can screw up
implementing PKCS "standards" due to all the options and versions. in the
link above it says DES or RC2 are used with 64-bit keys. You can look up on
NIST's website how long single DES (I'm not sure if they've published info
on RC2) is expected to last--it isn't very long at all. It's basically
compromised the moment you use it.

So if I have all my facts and assumptions straight, it almost doesn't matter
how long your passphrase is if the private key is published in PKCS#12
because it's encrypted using a weak algorithm which is faster to break than
an exhaustive password brute-force attempt.

Let's assume I'm incorrect and your tool (O2 or some version of PGP) will
export in a format that has a strongly encrypted private key. Now you're
talking about brute forcing the password. See
http://en.wikipedia.org/wiki/Password_strength#Entropy.2C_or_bit_strength for
some info on bits of entropy for given password lengths and
compositions--assuming they are randomly generated. Let's assume for the
sake of argument that the table is correct, and you use a truly randomly
generated passphrase. In order to have longevity on the order of years, you
should try to use a 128-bit equivalent passphrase. According to the table
that would be 20 printable ASCII characters (x21 to 0x7E). There's almost no
chance a human will be able to memorize it, however, so your security goes
down in other ways right there because the passphrase may be compromised
without brute forcing it.

There are so many assumptions being made here, and by all members of this
discussion including Dinis, it's ridiculous. Encryption is very hard to get
right and very easy to get wrong, and having "more encryption out there"
doesn't do anybody any good. If you're talking about making encryption more
accessible to the laymen, you need to make tools that are easier to use but
publicly vetted by experts, then you have to get market penetration--which
is something no tool has done yet. Even with the marketing power of Symantec
PGP has gone nowhere. Even with S/MIME being an open standard for email,
encrypted email has gone nowhere. Sad but true.

So after all this, Dinis still doesn't have any hard data to support how
long a private key protected by a passphrase will last if not locked down as
intended. And even if someone could point to, or perform, research on how
long it takes a given CPU to brute force the passphrase of a private key in
a given piece of interactive software or an exported format, we'd still have
to threat map it because we don't know if Dinis is up against foreign
governments or 13-year-olds with lots of free time. This is a pervasive
problem with risk analysis--when it's objective, it's so easy anybody could
do it, but when it's subjective (which it usually is), it's so hard anybody
might as well do it. So it comes down to educated guesses, which we can't
even make without very, very precise constraints around the problem, which
Dinis hasn't provided (e.g., what implementation of PGP? What version
thereof? What key export method? What types of characters are drawn from to
make the passphrase? How is it generated--by human or by RNG? How, exactly,
will the key be "published"? What/who are the threats and their
sophistication? What other business requirements are there that limit our
solution?)


On Thu, Oct 14, 2010 at 1:26 PM, James McGovern <JMcGovern at virtusa.com>wrote:

>  If you are married to the scheme of sharing keys but not necessarily the
> approach (e.g. PGP), then maybe there is an opportunity for you to noodle
> usage of the Identity Based Encryption work out of Stanford (with patterns
> from Voltage). The idea is that a key doesn’t have to be something based on
> complex algorithms such as factoring of large prime numbers but could be
> something as simple as using an email address.  Google for ‘identity based
> encryption’ for more information.
>
>
>
> *James McGovern
> *Insurance SBU
>
> *Virtusa **Corporation***
>
> 100 Northfield Drive, Suite 305 | Windsor, CT | 06095
>
> *Phone:  *860 688 9900 *Ext:  *1037 | *Facsimile:  *860 688 2890
>
> [image: cid:image011.jpg at 01CB08A4.F95CFA30] <http://www.virtusa.com/> [image:
> cid:image012.gif at 01CB08A4.F95CFA30] <http://www.virtusa.com/blog/> [image:
> cid:image004.gif at 01CB08A4.F95CFA30] <https://twitter.com/VirtusaCorp> [image:
> cid:image005.gif at 01CB08A4.F95CFA30]<http://www.linkedin.com/companies/virtusa>
>  [image: cid:image006.gif at 01CB08A4.F95CFA30]<http://www.facebook.com/VirtusaCorp>
>
>
>
> *From:* owasp-leaders-bounces at lists.owasp.org [mailto:
> owasp-leaders-bounces at lists.owasp.org] *On Behalf Of *Carlos Serrão
> *Sent:* Thursday, October 14, 2010 11:35 AM
> *To:* owasp-leaders at lists.owasp.org
> *Subject:* Re: [Owasp-leaders] Is it ok to share the PGP Keys and keep
> thePassPhrase private?
>
>
>
> Dinis,
>
>
>
> I'm not a crypto expert, but on any public-key based crypto system, the
> private key is supposed to be always private - even if the private key is
> protected by a passphrase.
>
>
>
> It's like using a strong security measure and then use a weaker one to
> protect the system. It doesn't make any sense.
>
>
>
> You have clever ways to subvert the passphrase without using a brute force
> attack:
>
> - dictionary attacks
>
> - social engineering
>
> - shoulder surfing
>
> - others.
>
>
>
> So, in my opinion this is a bad idea.
>
>
>
> Best regards.
>
>
>
> On 2010/10/14, at 10:38, dinis cruz wrote:
>
>
>
>  Here is a question to the Crypto experts (which I'm not).
>
> From a security point of view, is it ok if I publish both Public and
> Private PGP Keys but keep the PassPhrase secret?
>
> 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?"*
>
>  To see this in practice check out the latest script/tool that I just added
> to the OWASP O2 Platform <http://o2platform.com/wiki/Download> which
> dramatically simplifies the process of using PGP (creating keys,
> encrypting/decrypting text and encrypting/decrypting files):
>
>    - blog post:
>    http://diniscruz.blogspot.com/2010/10/tool-using-openpgp-to-encrypt-or.html
>    - Wiki page
>    http://www.o2platform.com/wiki/O2_Script/Tool_-_Using_OpenPgp_to_Encrypt_or_Decrypt.h2
>    - YouTube Video http://www.youtube.com/watch?v=_Cd8AfZyWMs
>
> As you can see, this O2 tool will really enable this workflow (sending the
> both Public and Private Keys to the client in a non-encrypted zip and then
> sending the PassPhrase in an offline/out-of-band method), so I'm really
> trying to figure out if this is a good idea :)
>
> Finally, for the really hard-core crypto guys, can you take a look at how I
> implemented the BouncyCastle Crypto APIs to make sure I did it correctly:
> http://code.google.com/p/o2platform/source/browse/trunk/O2_Scripts/APIs/OpenPgp/API_OpenPgp.cs
>
> Thanks
>
> Dinis Cruz
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>
> --
>
> Carlos Serrão
>
> ISCTE-IUL/ISTA/DCTI | ADETTI-IUL/NetMuST | PT.OWASP
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/843d09f7/attachment-0001.html 


More information about the OWASP-Leaders mailing list