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]

GPG and multiple recipients



On 10/17/2008 09:32 AM, Derek Atkins wrote:
> Tom Metro <blu-5a1Jt6qxUNc at public.gmane.org> writes:
>
>  =20
>> Dan Ritter wrote:
>>    =20
>>> Don Levey wrote:
>>>      =20
>>>> ...gpg generates its own key, encrypts the data with that, and then
>>>> the recipient's public key is used to encrypt the data key...
>>>>        =20
>>> In fact, this is what always happens, one recipient (R)  or n recipie=
nts
>>> R0..Rn. GPG makes a random key K, encrypts your message M with K, the=
n
>>> sends K(M) + R0(K) +... Rn(K).
>>>      =20
>> Right...because public key encryption is expensive (CPU intensive), so=

>> they use a symmetric cypher to encrypt the payload, and use PKI to
>> encrypt just the symmetric key.
>>    =20
>
> Not only is public key encryption expensive in terms of CPU, it's also
> extremely limited in the size of the message you can encrypt.  If you
> have a 2048-bit RSA key the message you can encrypt is less than 2K!
> That rules out most messages.  And when PGP first came out people were
> using 512-bit keys.  Imagine being limited to messages of under 60
> bytes.  Not very useful.
>
> When PGP 2.0 was released in September, 1992, it could only encrypt a
> message to a single recipient, even though it used this same Encrypted
> Session Key (ESK) methodolgy.  Multiple recipient support was added
> shortly thereafter, but I don't recall if that made it into 2.1.1 or
> 2.2 back in '92-93.
>  =20
Just one additional comment.  There is a technique called "session=20
keying". In essence you establish the session using the appropriate=20
keys, regardless of the type, but the data is actually encrypted using a =

key generated for the duration of the session. The reason for this is=20
that the security of an encryption key degrades with its use. While=20
there is a performance reason not to use public keys to encrypt and=20
decrypt the entire message, there is also a security reason in that you=20
want to limit the exposure of your private key whether it is a=20
asymmetric or symmetric key.  Another advantage of the session keying is =

that if an encryption method itself becomes weak because of a better=20
cracking method, the application can use a better method. We are seeing=20
this now with MD5 and SHA-1.

--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846








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