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 | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Re: GnuPG/OpenPGP primer?



 On Wed, Jun 18, 2008 at 10:53:26AM -0400, Don Levey wrote: 
> At the risk of asking a ridiculously elementary question, does anyone 
> have a pointer to a GPG/PGP primer, including such conceptual things as 
> "what is the problem we're trying to solve" and "why bother", as well as 
> the basic mechanics of it all? 


http://www.cryptographyworld.com/ has some good bits. 

The problem is this: Alice and Bob would like to exchange 
messages. They want privacy -- Eve  should not be able to listen 
in on their conversation. They want identification and 
authentication -- Alice needs to be sure that she's talking to 
Bob, not to Mallory pretending to be Bob. And they want 
integrity -- the messages should not be changed between Alice 
and Bob. 

Alice and Bob could use one-time pads. This is basically a block 
of random numbers that both Alice and Bob know. For every 
character in a message, Alice XORs it with the next number on 
the pad, and marks the pad so she doesn't use it again. As long 
as the pad isn't stolen or re-used, this is very secure. But the 
pad needs to be as long as all the data that's ever sent with 
it; you can't use the pad to send updates to the pad. If Alice 
and Bob can meet regularly to share new pads, and they can keep 
them securely, this is a great method. 

But it's likely that Alice and Bob can't get together often. So, 
they could use an algorithm to produce pseudo-random numbers to 
act as a pad. Pseudo-random numbers are susceptible to analysis; 
that's how the British broke the German Enigma cypher system in 
World War II. 

And that brings us to public key systems, in which the 
algorithms are well-known and the keys come in two parts: a 
private key which you keep very, very secret and a public key 
that you publish on a keyserver and on your website and so 
forth. The properties of the classic public key systems are as 
follows: 

Take a message and encrypt it with your private key: Now anyone 
can decrypt it with your public key and assure themselves it 
came from you, or at least someone with your private key. 

Take a message and encrypt it with Bob's public key: Now only 
Bob's private key can decrypt it. 

Take a message, encrypt it with your private key (signing) and 
then Bob's public key. Now only Bob's private key can decrypt 
it, and then he has to decrypt it with your public key, showing 
that the message was from you to him. 

Given that the math for all the public systems is a bit heavy, 
lots of systems are hybrids, in which a one-way hash function is 
applied to some text, and then the hash output is signed to show 
evidence of tampering along the way. 

-dsr- 

-- 
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference. 

When freedom gets lots of exercise, it protects itself. 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


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