> > OK. The text of the message is not encrypted with a users key; the > > text of the message is encrypted using a symmetric key - the key for > > *that* method (the session key) is encrypted using public keys, and, > > the important bit, there can be multiple public key encryptions in one > > message. So for a command line example you can encrypt a file using > > > > gpg -r ID1 -r ID2 -r ID3 -e > > > > Where one of those IDs is your own - hence you will be able to decrypt > > the file because you will be able to decrypt the session key. > > > > P. > > Ah, I think I'm beginning to understand. So this is another form of > encryption, still using the receiver's public key, and s/he still has to > use his or her private key to decrypt the message?
No, it's the same form of encryption that has always been used by PGP/GPG, that's how it has always worked. Encrypting a large file with a large key is hard work, so the file is encrypted with a small, throw away, symmetric key - usually a 256-bit key these days. That session key is then encrypted using the intended recipient's public key and placed at the beginning of the file. Have you never wondered why a tiny file produces such a large encrypted file - if it were purely encrypted with the recipient's public key, then a single character file would be encrypted to a single character. Instead a single character file goes to a 330-ish character encryption (depending on the size of the keys) - it's all the overhead of session key encryption. Add another user to the encryption and the file will expand again. To see what's going on run gpg with the '-vvvv' option. That will also tell you if the files you are sending out are encrypted to the people you intended. P. _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
