Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] PGP Basics



On 10/10/2011 09:28 PM, Edward Ned Harvey wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Kyle Leslie
>>
>> Hola Everyone.  With the recent talk about PGP and the growing need for
> its
>> use at my company I have been trying to learn about it.
> I'll encourage you to look at S/MIME instead.  It's much easier.
>
> Surely some people on this list will say PGP is more secure, and as with
> anything, there's a grain of truth which is probably not represented
> entirely accurately.  The fundamental difference is this:  S/MIME is based
> on SSL, which means anything you send/receive is automatically checked for
> validity using the built-in SSL root Trusts.  These are the same
> organizations that are used to trust https traffic, or anything else based
> on SSL.
>
> So the grain of truth is like this:  As long as you're trusting a 3rd party
> such as verisign or thawte, then there's an attack vector which otherwise
> doesn't exist.  An attacker only needs to somehow compromise one of these
> root trusts, and then they can forge signatures.  Although rare, this has
> been known to happen.  When it happens, the compromised certificate
> authority promptly revokes any compromised certs (as soon as they discover
> they've been compromised)...  So it's important to keep current with system
> updates.
>
> On the flip side, with PGP you don't have automatic trusts.  You need to
> somehow decide you trust someone's cert based on some kind of out-of-band
> information.  Maybe because the person told you over the phone "I'm sending
> it now" and then it arrived a second later, or whatever.  The problem with
> something like this is...  Just like the "Are you sure?" prompts that you
> get everytime you try to do anything in windows...  People just make a habit
> of always clicking "Yes" without thinking about it.
>
> Everyone has their own opinions, about which is more trustworthy and which
> is more convenient.  My opinion is that if you're deploying one of these
> technologies for your company, IMHO your users would be more secure with
> S/MIME, and it's much more convenient.  If you were only deploying it for
> yourself, then you as an interested and technical user might actually get
> better security out of PGP.
>
> You can get free S/MIME certs from startssl.com, and probably a number of
> other locations.  If you're interested, I have an example here:
> http://dl.dropbox.com/u/543241/Digital%20ID%20Step%201%20-%20Create%20Cert%2
> 0IE9%20Win7.pdf
> and
> http://dl.dropbox.com/u/543241/Digital%20ID%20Step%202%20-%20Outlook%202010.
> pdf
>
It does come down to trust, but also a need. I can pretty well trust 
those whose keys I have signed, and who have conversely signed mine. 
But, where is my need? I don't have much need, and until JABR gets a new 
key I don't much trust him :-). But, in a corporate environment when you 
are exchanging email, both digital signatures as well as encryption are 
workable. So, in a corporate environment, you might upload your public 
key to the corporate key server (assuming PGP). By having only employees 
being allowed to upload, you can establish trust as long as it is being 
properly managed. If an employee leaves, then there should be a 
procedure to decertify his/her key. Same would apply to ssl certs. I 
think in the original poster's situation, he is in a corporate PGP 
environment,

-- 
Jerry Feldman<gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org