On May 4, 4:02*pm, Yves Stadler <yves.stad...@gmail.com> wrote:
> Hi,
>
> The subject is problematic. If you need to exchange encrypted
> information with someone, the receiving party should be aware of the
> fact you will use cryptography to communicate with them. If this
> prerequisite is met, you can start thinking of sending secure email.
>
> The first problem you will encounter is to choose the encryption
> algorithm. Basically you can choose between asymmetric and symmetric
> encryption. In both case, the next problem is to exchange keys.
>
> If you agreed to choose symmetric encryption, both side will use the
> same password. To share this key, you must use a secure communication
> channel, or use a protocol like the Diffie-Hellman key exchange. Then,
> find a program that can code plain-text with the chosen algorithm.
> Copy the output to any mail client you want. Your partner will then
> proceed backwards, using the program to decode.
>
> In you choose asymmetric encryption, key exchange requires you to acquire
> the public key of the receiver. The key can be passed through an
> unsecured connection. Though you need to be able to assess that the key
> comes from the right person (key is distributed on their website, or is
> signed through web-of-trust mechanism, ...). Then a program like
> GPG can be used to encrypt a mail using this public key. Only the person
> owning the corresponding private key is able to decrypt.
>
> Many desktop mail-client are now PGP/GPG enabled, but it still requires
> configuration.
>
> In the same fashion, encryption is possible using certificates. Look at
> S/Mime for more information
>
> In conclusion, it is very difficult to initiate a secured conversation
> by mail with someone who does not expect it. By the way, it is more than
> probable that your contact do not have the required tools to decrypt
> mail (and can't install them because of company policy, or user-rights
> to do so).
>
> > I would like to able to send information to companies, on an
> > occasional basis, where it would be best if the information was
> > secured.
>
> This adds more challenge. Since you will have to do the setup job
> every time.
>
> > For example, if I could encrypt the message attachment and they could
> > click on it, provide a password, and then read the mail.
>
> This is a no-go too. In fact, if the company security manager did his
> job, attachments are filtered and/or removed so as to prevent virus
> infiltrations. Don't expect to be able to send binary files that
> autoextracts.
>
> On a related topic, you can still send authenticated messages without
> disrupting (too much) standard mailing. For example (you should see it
> on this message) asymmetric cryptography allows you to sign messages. It
> adds some information which allow someone with your public key to verify
> that the message has really been sent by you. Eventually someone who is
> not aware of digital signature can disregard signature information and
> just read the message.
>
> Hope it helps you.
>
> Yves
>
> *signature.asc
> < 1KViewDownload
Yves.
Thanks for the information.
I planned only to send text files that contain personal or business
information.
However, it seems that my idea of being able to send an encrypted
attachment that would contain, in the clear, a piece of information
that they would know (eg, use my product ID as password) so that they
could it as the password to open the attachment is not an option.
I realise the the attachment would need to contain a facility to open
the file.
On May 5, 5:19*am, species8350 <not_here.5.species8...@xoxy.net>
wrote:
> On May 4, 4:02*pm, Yves Stadler <yves.stad...@gmail.com> wrote:
>
>
>
>
>
> > Hi,
>
> > The subject is problematic. If you need to exchange encrypted
> > information with someone, the receiving party should be aware of the
> > fact you will use cryptography to communicate with them. If this
> > prerequisite is met, you can start thinking of sending secure email.
>
> > The first problem you will encounter is to choose the encryption
> > algorithm. Basically you can choose between asymmetric and symmetric
> > encryption. In both case, the next problem is to exchange keys.
>
> > If you agreed to choose symmetric encryption, both side will use the
> > same password. To share this key, you must use a secure communication
> > channel, or use a protocol like the Diffie-Hellman key exchange. Then,
> > find a program that can code plain-text with the chosen algorithm.
> > Copy the output to any mail client you want. Your partner will then
> > proceed backwards, using the program to decode.
>
> > In you choose asymmetric encryption, key exchange requires you to acquire
> > the public key of the receiver. The key can be passed through an
> > unsecured connection. Though you need to be able to assess that the key
> > comes from the right person (key is distributed on their website, or is
> > signed through web-of-trust mechanism, ...). Then a program like
> > GPG can be used to encrypt a mail using this public key. Only the person
> > owning the corresponding private key is able to decrypt.
>
> > Many desktop mail-client are now PGP/GPG enabled, but it still requires
> > configuration.
>
> > In the same fashion, encryption is possible using certificates. Look at
> > S/Mime for more information
>
> > In conclusion, it is very difficult to initiate a secured conversation
> > by mail with someone who does not expect it. By the way, it is more than
> > probable that your contact do not have the required tools to decrypt
> > mail (and can't install them because of company policy, or user-rights
> > to do so).
>
> > > I would like to able to send information to companies, on an
> > > occasional basis, where it would be best if the information was
> > > secured.
>
> > This adds more challenge. Since you will have to do the setup job
> > every time.
>
> > > For example, if I could encrypt the message attachment and they could
> > > click on it, provide a password, and then read the mail.
>
> > This is a no-go too. In fact, if the company security manager did his
> > job, attachments are filtered and/or removed so as to prevent virus
> > infiltrations. Don't expect to be able to send binary files that
> > autoextracts.
>
> > On a related topic, you can still send authenticated messages without
> > disrupting (too much) standard mailing. For example (you should see it
> > on this message) asymmetric cryptography allows you to sign messages. It
> > adds some information which allow someone with your public key to verify
> > that the message has really been sent by you. Eventually someone who is
> > not aware of digital signature can disregard signature information and
> > just read the message.
>
> > Hope it helps you.
>
> > Yves
>
> > *signature.asc
> > < 1KViewDownload
>
> Yves.
>
> Thanks for the information.
>
> I planned only to send text files that contain personal or business
> information.
>
> However, it seems that my idea of being able to send an encrypted
> attachment that would contain, in the clear, a piece of information
> that they would know (eg, use my product ID as password) so that they
> could it as the password to open the attachment is not an option.
>
> I realise the the attachment would need to contain a facility to open
> the file.
>
> Best wishes
>
> S
Yves,
It has just occured to me that I could solve my problem by simply
creating a file in MS Word, then password protect it, and send this as
an attachment to an email. The email could contain a piece of
information that they, the company would know, e.g., my ID code, and
use this to open the Word document. In addition, most companies would
have MS Word. installed on their pc's
> It has just occured to me that I could solve my problem by simply
> creating a file in MS Word, then password protect it, and send this as
> an attachment to an email. The email could contain a piece of
> information that they, the company would know, e.g., my ID code, and
> use this to open the Word document. In addition, most companies would
> have MS Word. installed on their pc's
>
> Good wishes.
>
Another alternative is to send/provide the recipients a "password" in
advance, then send the recipients files in a pssword protected ZIP file.