Point of view regarding LISA 2002
Tue Oct 1 21:19:02 2002
Anthony E. Greene schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 01-Oct-2002/18:11 +0200, markus_kampkoetter
> <email@example.com> wrote:
> >Michael Tokarev schrieb:
> >> Adam Shostack wrote:
> >> 
> >> > Now, are these GPG's fault? In most cases, no, they're not. But
> >> > they're problems that we need to address to get say, 10% of the email
> >> > on the net to be encrypted. And if thats a goal, then we need to
> >> > examine the things that are preventing us from hitting it.
> >> Yeah - learn users to encrypt their emails and there will be
> >> many problems with viruses who will try to use encryption too
> >> thus making it impossible to detect in-transit... Oh well... ;)
> >> /mjt
> >i do not agree with you. at least you will know for sure who sent the
> >virus to you ;))) and worms cannot use cryptotechnology easily.
> >(one day later)
> >or can they? is it possible to write a script that automatically encrypts
> >to all the keys on ones keyring and sends itself to the corresponding
> >addresses? even if, it never will be able to sign.
> How about a worm that does this when run:
WHEN RUN! apart from m$outlook, which mua allows attachments to be run without
asking the user?
> 1. Read the userids of the keys on the public keyring. Make note
> of the userid of the first key.
> 2. Create a separate secring and pubring using the userid from the
> first key on the original public keyring.
> 3. Upload this key to multiple keyservers.
> 4. Send itself as an encrypted attachment to each recipient on the
> original pubring. Sign the message with the newly created key.
> If the recipient is configured to automatically fetch keys as needed, and
> is reading mail online, they may not realize that the key used to verify
> the sig was just fetched. People generally do not pay that much attention
> to key IDs. Even if they notice the fetching operation, they might not
> that that it was significant. The attachment would look legitimate and the
> recipient might run the executable, thinking that it is safe because it
> was signed and encrypted from someone they know.i
nice hack, so we have to take a close look at the key if an executable is
attached and not run executables until we asked the "original" sender to confirm
"his" action. seems to be easy to avoid this kind of attack (because hardly
anybody will run executables that they do not expect in advance) - too easy....?