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

Jim Manico jim.manico at owasp.org
Sun Oct 17 01:48:57 EDT 2010


> For example, why would  Hotmail, Gmail, etc implement transport-level
encryption (SMTP over TLS) which would increase CPU utilization of their
infrastructure that would neither be visible to the user, the user would not
pay for it, nor would it drive any additional advertising revenue. Altruisms
are nice, but the marketplace is primarily driven by the ability to pay


 

By the same token, Google is realizing the email based transport encryption
is critical to the success of their company. Perhaps it had something to do
with so many gmail accounts getting compromised at coffee shops. J SMTP/TLS
is now standard when you set up Gmail for thick clients. And Gmail has an
option that forces all GMAIL communication to over HTTPS, AND Google has a
reasonable rating at SSLLabs for HTTPS configuration. It’s a step in the
right direction. You can even go this route
https://addons.mozilla.org/en-US/firefox/addon/592/ if you want real
enterprise grade email security via gmail.

 

- Jim

 

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of James McGovern
Sent: Saturday, October 16, 2010 2:19 AM
To: owasp-leaders at lists.owasp.orged
Subject: Re: [Owasp-leaders] Is it ok to share the PGP Keys and keep
thePassPhrase private?

 

May I ask a few “refining” questions of Dinis?

 

1.       Is the requirement to externalize the private key used in
encryption/decryption operations so that it is NOT embedded within the
application? If so, since I saw that O2 was mentioned which hints that you
are probably using C# which probably hints that you are running MS Windows
(will ignore Mono for now) that you could have a Passphrase unlock either
the Windows keystore that stores the private key or a custom implementation
of your own keystore.

2.       To make passphrase strength more strong would require adding some
“salt”. Again, if you are using C# and Windows, there is the ability to hide
the value used by going after things that are local to the machine such as a
MAC address, GUID or arbitrary value in the registry. I think the key to
this discussion may be less about the “encryption” and more about “digest”
(???) Your passphrase is less likely to be compromised if the salt varies
based on installation.

 

As far as email encryption having gone nowhere, it is important to
understand both successes/failures in this space. First and foremost, I can
say that there was a loudmouth Architect (and Hartford OWASP chapter leader)
who evangelized the need for every insurance agent/carrier to install SSL
certificates (could be self-signed or VeriSign) so that the
industry-at-large could comply with Mass (the state) regulations. Carriers
who have enterprise-class products such as Exchange, IronPort, etc were able
to implement this very easily and cheaply. 

 

The challenge of email encryption is fast becoming more of a “consumer”
problem. For example, why would Hotmail, Gmail, etc implement
transport-level encryption (SMTP over TLS) which would increase CPU
utilization of their infrastructure that would neither be visible to the
user, the user would not pay for it, nor would it drive any additional
advertising revenue. Altruisms are nice, but the marketplace is primarily
driven by the ability to pay


 

James McGovern
Insurance SBU 

Virtusa Corporation

100 Northfield Drive, Suite 305 | Windsor, CT | 06095

Phone:  860 688 9900 Ext:  1037 | Facsimile:  860 688 2890  

 <http://www.virtusa.com/> cid:image011.jpg at 01CB08A4.F95CFA30
<http://www.virtusa.com/blog/> cid:image012.gif at 01CB08A4.F95CFA30
<https://twitter.com/VirtusaCorp> cid:image004.gif at 01CB08A4.F95CFA30
<http://www.linkedin.com/companies/virtusa>
cid:image005.gif at 01CB08A4.F95CFA30  <http://www.facebook.com/VirtusaCorp>
cid:image006.gif at 01CB08A4.F95CFA30

 

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Matthew Chalmers
Sent: Friday, October 15, 2010 3:56 PM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Is it ok to share the PGP Keys and keep
thePassPhrase private?

 

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  

 <http://www.virtusa.com/> Error! Filename not specified.
<http://www.virtusa.com/blog/> Error! Filename not specified.
<https://twitter.com/VirtusaCorp> Error! Filename not specified.
<http://www.linkedin.com/companies/virtusa> Error! Filename not specified.
<http://www.facebook.com/VirtusaCorp> Error! Filename not specified.

 

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 <http://o2platform.com/wiki/Download>  O2 Platform 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/Open
Pgp/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

 


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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1397 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 744 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1211 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 789 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 763 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101017/91b8758e/attachment-0007.gif 


More information about the OWASP-Leaders mailing list