AW: E-Mail Encryption: Why Isn't Everyone Doing It?

Thu Oct 24 13:40:02 2002

--=_Knzjz1fZ.5XiMkIG0nnxfhpcRy8C.P
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Per, you wrote plenty of good stuff i=B4d like to comment inlined.

> -----Urspr=FCngliche Nachricht-----
> Von: gnupg-users-admin@gnupg.org=20
> [mailto:gnupg-users-admin@gnupg.org] Im Auftrag von Per Tunedal
> Gesendet: Donnerstag, 24. Oktober 2002 11:36
> An: gnupg-users@gnupg.org
> Betreff: Re: E-Mail Encryption: Why Isn't Everyone Doing It?
>=20
> An other great obstacle is that people don't want to learn=20
> anything about=20
> encryption. And thus cannot take any responsibility for their=20
> own security.=20
> They can (and will!) do a lot of mistakes that compromises=20
> their security.

Agree but if you let them first work with a testing keypair they can get
familiar with the wholestuff without too much of damage.

>=20
> - - The idea to have two different passphrases: one for=20
> signing and one for=20
> decryption is brilliant. It would make it possible to have a greater=20
> protection for the signing key and doing automatic=20
> decryption. That is=20
> important: you can have a signing key with a long life and=20
> regularly change=20
> the encryption keys (without loosing the signatures on your=20
> signing key and=20
> thus "transferring" the trust to the new encryption subkeys=20
> you create).

Agree again but most ppl are not even able to remember a single
passphrase, with 2 of them it will be even harder.=20

> - - I belive GPG Relay is a great way in the right direction.
>  http://sites.inka.de/tesla/gpgrelay.html

If then one could add the complete functionality of a GPL=B4ed GPGShell =
to
GPGRelay it would be a great step ahead.

> - - Key exchange is still complicated. Why not automatically=20
> download keys=20
> from keyservers for all e-mail adresses in your address book?=20
> And do the=20
> same whenever you add a new adress? It would be fine with=20
> such a feature in=20
> the plug-ins for Outlook Express and Eudora!

yep, still my auto-key-retrieve produces eof-errors all the time

> You simply have to trust=20
> the other person.

That sounds like the solution for all of our problems :))

> But it does matter if I send something that I do not want to=20
> be read by=20
> ANYONE but the intended recipient. Then I must trust the recipient -=20
> otherwise he could print the document and give it away anyway.

AFAIK this all is intended to secure the way to a reciever, not to
secure the reciever ?

> By the way I read an article on how to implement PGP-encryption in a=20
> company. The author suggested that an administrator would create the=20
> keypairs for all users and sign them with a company signing=20
> key. Then he=20
> should distribute the keys to the users and keep a backup of=20
> the public=20
> key. "But the secret key should not be kept". What would prevent the=20
> administrator to keep the secret keys for any reson? How=20
> would you know how=20
> many people controls the secret key for a user you encrypt to?

Again, with GnuPG one can do everything that is needed to keep things
secure within his own Sphere of influence. If others do not share our
thoughts on security risks we can not blame them for that but if risks
come true at least they can not blame us.=20

Greetz from Berlin, Mortimer

> Per Tunedal
>=20
>=20
> This mail was signed (Inlined PGP-Message).
>=20
> ,-----GnuPG output follows (current time: Thu, Oct 24 2002 -=20
> 11:57:24)--
> |
> |     Hinweis: Alte voreingestellte Optionendatei=20
> 'C:/Programme/GnuPG/Keys\options' wurde ignoriert
> |     ASCII-H=FClle: BEGIN PGP SIGNED MESSAGE
> |     ASCII-H=FClle: Hash: SHA1
> |     ASCII-H=FClle: BEGIN PGP SIGNATURE
> |     ASCII-H=FClle: Version: GnuPG v1.2.0 (MingW32) - GPGrelay v0.90
> |     Urspr=FCnglicher Dateiname=3D''
> |     Unterschrift vom 10/24/02 11:41:03 , DSA Schl=FCssel ID 7905AAA9
> |     Korrekte Unterschrift von "RADVIS <pt@radvis.nu>"
> |                         alias "Info RADVIS Tjanstekvalitet=20
> <info@radvis.nu>"
> |                         alias "Jobb RADVIS Tjanstekvalitet=20
> <jobb@radvis.nu>"
> |     Schl=FCssel 4DD2209A: Akzeptiert als vertrauensw=FCrdiger =
Schl=FCssel
> |     Schl=FCssel 04A33061: Akzeptiert als vertrauensw=FCrdiger =
Schl=FCssel
> |     Schl=FCssel 37E7FBDD: Akzeptiert als vertrauensw=FCrdiger =
Schl=FCssel
> |     Schl=FCssel 3485782E: Akzeptiert als vertrauensw=FCrdiger =
Schl=FCssel
> |     WARNUNG: Dieser Schl=FCssel tr=E4gt keine vertrauensw=FCrdige=20
> Signatur!
> |              Es gibt keinen Hinweis, da=DF die Signatur=20
> wirklich dem vorgeblichen Besitzer geh=F6rt.
> |     Haupt-Fingerabdruck  =3D 09D5 1EA1 8056 0D6C 1684  4D22 57E5 =
A315
> | 7905 AAA9
> |
> `-----------------------------------------------
>=20

--=_Knzjz1fZ.5XiMkIG0nnxfhpcRy8C.P
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32) - GPGrelay v0.90

iD8DBQA9t9xU8w7YcTfn+90RArjFAJ9x86dHKKRpJhZ8VaZwqVAlAxOPiwCfZxiu
gkhKg+L6p5Y9GY32X/BEpos=
=heI8
-----END PGP SIGNATURE-----

--=_Knzjz1fZ.5XiMkIG0nnxfhpcRy8C.P--