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

James McGovern JMcGovern at virtusa.com
Fri Oct 15 16:49:06 EDT 2010


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/>    <http://www.virtusa.com/blog/>    <https://twitter.com/VirtusaCorp>    <http://www.linkedin.com/companies/virtusa>    <http://www.facebook.com/VirtusaCorp> 

 

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  

Error! Filename not specified. <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> 

 

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

 


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/20101015/a8f63910/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1397 bytes
Desc: image001.jpg
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/a8f63910/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 744 bytes
Desc: image002.gif
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/a8f63910/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1211 bytes
Desc: image003.gif
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/a8f63910/attachment-0005.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 789 bytes
Desc: image004.gif
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/a8f63910/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 763 bytes
Desc: image005.gif
Url : https://lists.owasp.org/pipermail/owasp-leaders/attachments/20101015/a8f63910/attachment-0007.gif 


More information about the OWASP-Leaders mailing list