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