Thursday, January 16, 2014

PGP best practices and security considerations from socpuppets

In this post, we will look at some basic security concepts & concerns with using  the  GNU implementation of PGP, aka thru-out this post as  just  "gpg".

I will try to outline some thoughts that you should keep in mind,  &  some common  best practices you should be aware of;

1st  you should be aware of  your capabilities.

By the execution of  gpg  &  with the --version option, you can quickly discover your capabilities



2nd The key length that you  decide on, has a direct impact to the strength and time used during the encryption/decryption process.

This is a touchy topic on what size key to use. But here's my thoughts on the matter. The longer the key is obviously more stronger. The earlier  security consultants always indicated a 1024bit key-size was acceptable.


note: The  same argument was made towards SSL certificates btw. But most current root CAs uses a 2K bit key-sizes now

But............ Nowadays the general accepted norm is for a key-size of 2K bits or bigger for PGP.

Yes, today's computers do NOT have the capacity to brute-force this key-size,  but who knows what will come up next month, next-year or next decade.  Or what the intelligence community is  currently working on.   :)

So if  you data is of a highly sensitive nature; "  then a stronger,  and large key-size is required ". Also if your paranoid, or believe in the possibility of a electronic version of  Apocalyptic  events. Than the deployment of  the largest key-size is a must.




3rd, to go along with the key-size, you should set a expiration for your key.

This will force you to update and refresh your key upon expiration. Take one of mine older pgp key that was upload back around 1997



  • I no longer use this key
  • have no access to revoke that key
  • nor have access to that account  ( yes I thought ken,felix@usa.net would never go away ...boy was I wrong :)  )
  • and wish I had set a lifetime on that key

Get in a habit of establishing some type of lifetime for any public-key that you publish. You can always edit the key ( --edit-key ) and change the  lifetime, but that could become an hassle.

If you should ever loose access to your master key, the expiration could be a life saver as in my past experience and within the example of ken.felix@usa.net.

NOTE:  Keep in mind, that key expirations,  only protects against future files and documents. A key that's compromised, can read in to any document that was encrypted by that key earlier .


A few of my counterparts also started to use &  craft public-keys with shorten expiration dates.  I never really caught on this policy/procedure of a very short key lifes ( < 30days ). This mainly envolves around  PFS (forward secrecy ) which is lacking in PGP. Basically beacuse the keys are static and long winded, their's no refreshing of any encryption keys. So if a key is compromised, everything under it is corrupted and integrity is now broken.

4th, secure your  master key 

That master key that's used in gpg,  should be secured. Here's why; " if your on a multi-user systems and have numerous super-users, and one of them has access to you key, then they have access to your data "

This  breaks the integrity of your security chain. Here's a real life case of how this could be problematic.

A friend of mine worked for a big telecom provide back in the late 90s. One of the employee started sending  nasty and threatening emails to numerous  local and gov officials. Once a email was sent to a senator & threat to the Vice President, the FBI executed a electronics collections warrant  at his home, place of employment,   and named all systems that this guy used for sending mail or had the possibility of using ( hah ... this what our gove does with loopholes )

Okay are you following me?

The machine that he was using, had other end-users  PGP keys installed on it. Once the FBI takeath-away, they takeath  for keeping.


 Yes all of those other systems users where caught up in a big collateral damage nightmare, and had no access to any of their encrypted stuff, nor access to their  master key for revoking any other keys. 

" And we can pretty much trust that the FBI didn't look at their data or compromised anything "


What made matters so much worst, all of the systems backups where seized by the FBI during the course the warrant execution and investigation. So a few dozen to almost  hundred of end-uesers where impact,  & just by one bad apple amongst them.

And if your sitting here reading this, keep these thoughts  in mind  & the following;


  • The USA gov is becoming the biggest enemy to your privacy of data & over the internet
  • you doubt me read up on  on how intrusive the Patriot act, CALEA,CISPA,etc...
  • or the try to sneak in via other propose bills ( look at how loose  HR 1981 was written... numerous loophoels exits & their's a  reasons why  )
  • you are MORE at risk by your own government, than joe blow the hacker or taliban or al-qaeda
  • DHS and FBI are probably the 2 most un-trusting gov agencies on plant earth followed by BATF, & when it comes to your privacy and civil liberties be trampled
              ( all in the name of security or protection or you the american  citizen  )




5th, use a strong pass phrase

Yes just as important as #4,  the  #5 spot  is equally important. You can have the best encryption ciphers, implement  the  strongest key-size,  but used a simple and easy pass phrase. You choice of pass-phrase can defeats all of the former.

The old saying of; " your as strong as you weakest link, truly  applies"

So for a attacker to do real  damage, he would need access to you master key ( access ),  and then access to your pass phrase. So secure them! I can't  say enough on this matter.


6th, be aware that GNU pgp implementations creates 2 keys

By default,  gpg creates a  "signing key" and a "encryption" key. By using the edit-key, we can clearly see the differences;



For  my key id #96DE58DC, we have a signing key and a encryption subkey and then I also crafted for this blog, a 2nd subkey for signing using a 4096bit key-size. All of these subkeys are children of the master key.

note:  By default gpg know what key to use & for what function;  signing ( authenticity ) vrs encryption.

!!!!!!!!!   DO NOT SIGN AND ENCRYPT YOUR DATA WITH THE SAME KEY   !!!!!!!!!!!!

Use the correct key for the proper task


7th, when adding a key or searching for a key for a user,  always validate the user and key fingerprint


Here's a funny SNAFU thing  that I did mainly years ago when I first  started  out with PGP. I retrieved a key for a user name  <john.smith> for example.  But I didn't know their was 2 <john smith>  one  at the same email domain of my recipient. So for  the 1st john.smith,  I was encrypting sensitive file using  the 2nd john smith public-key.


Okay fine. The data I was sending, could not be decrypted by the 1st john.smith who was the true recipient btw. But if john smith #2, has access to that data file, he could have decrypted the data and snoop the contents intended for the 1st john smith.

" Boy  did I end up with egg on my face "


To show you how you could easily mistaken the recipient,  take at look at  just one basic simple search against my  username,  &  by  using a short name of  "ken.felix"


I give you a hint, that's just a few of my  popular published  PGP keys that are  on the public key-servers. I probably have a half dozen or more that do have ken or felix in the description :) and then  a few more that are not listed on any public-key-servers or keys that I share amongst my close friends  or associates in my  ITsecurity circle :) So if your ever in doubt, ask the recipient to validate the key fingerprint.

I've started the habit of supplying the fingerprint on my business cards, or via a webpage,  within  the signature line of my emails. Even once, I used a DNS txt record for listing my keyid.

Whatever you do,  just validate it!


8th, don't use constant in your email  cleartext before encrypting

This is a touchy topic, but major cryptologist warns us,  that if you place signatures or other various items that are constant thru out all of your messages, this can opens you up for a possible reverse-engineering of your private-key ( once again the paranoia )




If you think about it,  and about the earlier commeny on "PFS"  or lack of "PFS" to be specific. If you take the same key, the same data, and encrypted 10x times, you will get the same ciphertext. 

So if your always add that confidential banner, discolusre or signature, you have now generate the same exact cipher-text. 

I myself is not too concern with is, nor have I ever heard of one case of some trying to  reverse  engineering ,  to extract the  private-key. I personally don't think this is even feasible and if it was, than all of the PKI concepts wouuld be flawed. What this might do is disclose your hand somewhat as to the data that present.

PGP has numerous flaws in that it doesn't  encrypted subject line or mail-headers. So if the NSA is using the best known  surveilance network ever created  ( cough.....cough ..... the internet ) , then your showing your cards.


The 9th item,  if data is sent encrypted, than keep it encrypted

Okay the reason for this statement is simple. Encryption should be looked at as a end-2-end concept. Once you have no more need for the data, you should revert it back to it's encrypted state or better yet, delete it. It way much easier to protect static data,  if you woudl just  delete it  after  use :)



note: if you ever been in  the military or watched a few Mission Impossible  movies, what happens to the secret text after it been delivered and read?  Hint,  You destroy it or it self-destructs  !


It's extremely difficult to  recover a message or secret,  if you burn it. :)



My 10th and final, symmetric encryption is also an option

This has nothing todo with  PGP and public key encryption in general, but I thought I would mention it. Gpg has the capacity to do a simple symmetric encryption. And by providing a pass-phrase during the encryption stage,  you can then communicate that to the final recipient(s)

(example)


The reason that I'm  mentioning this, you might have multiple recipients that don't know how to import a public-key or  just multiple recipients. So a simple symmetric encryption could be the most effective way to secure data for transport.

I hope  that you found this information useful & handy.

Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(    @   @  )=
          o
       /     \  
   

=(  @   @  )=
           o
        /     \

No comments:

Post a Comment