Red Hat DIRECTORY SERVER 8.1 - 11-01-2010 Manual de usuario descargar pdf (Pagina 54)

Random Hacker's public key, as shown in the figure, and click Ok. The

message would then be sent to [email protected] encrypted with John

Random Hacker's public key.

If I had to send mail to [email protected] often, it would be worth

creating a per-recipient rule that says “Encrypt all mail that is sent to the

address [email protected] with the public key associated with address

[email protected]”. This can be done directly from the Key

Selection window by clicking the Create per-recipient rule(s) button.

Alternatively, if John Random Hacker intends to use often his alias address, he

should add the user ID [email protected] to his public key, and

redistribute the updated key.

As you have learnt, a message can be encrypted with more than one public key.

In fact, it is usually encrypted with at least two public keys: yours (to let you be

able to read a copy of the message) and the recipient's.

To be more precise, OpenPGP uses hybrid encryption. First it generates a

random session key, and encrypts the message with the session key using a

symmetric algorithm; then, for each intended recipient, it encrypts the session

key with the recipient's public key and adds each encrypted session key to the

encrypted message. It then builds an OpenPGP block, which includes an

header containing the key IDs and user IDs of any public key the message has

been encrypted with. Each recipient then receives the same OpenPGP block.

As a consequence, it is not possible to send to multiple recipients a message

that is encrypted for some recipients and unencrypted for others. The message

is sent out either encrypted or unencrypted for the whole list of recipients.

That being stated, you should not send encrypted messages to Bcc: recipients,

because from the OpenPGP block each recipient is able to tell the identities of

the others – hence thwarting the purpose of the Bcc: field. While Enigmail is

able to do some workaround to hide the Bcc: recipients from the header, as a

side-effect this could block users of other products (e.g. PGP Corp.) from being

able to decrypt the message.

1 2 ... 49 50 51 52 53 54 55 56 57 58 59 ... 105 106

Sin comentarios

Red Hat DIRECTORY SERVER 8.1 - 11-01-2010 Manual de usuario Pagina 54