Re: Symmetric encryption algorithm with group like properties

From: Han (hg_at_safeblue.com)
Date: 11/10/04 

Date: 10 Nov 2004 11:37:31 -0800

Peter Fairbrother <zenadsl6186@zen.co.uk> wrote in message news:<BDB76E29.73AD5%zenadsl6186@zen.co.uk>...
> Han wrote:
>
>
> > Big picture is always the most difficult one. Let me try.
> >
> > I believe a person's emails contain a lot of information and he/she is
> > entitled to a system that keeps them as private as possible. Each
> > email may not contain a lot of information but when they are taken as
> > a whole, emails can be very enticing for certain unwanted parties.
> >
> > Solutions that exist today are not as secure as they can be. I see two
> > major threats: The (employees working at a) service provider that
> > stores a copy of all the emails and malware on someones computer.
> >
> > I want to create a system that keeps emails private against these two
> > threats. I think I the solution I explained in my previous posts
> > satisfies my privacy concerns, thus I'm looking for a protocol that I
> > can use to implement such a system.
>
> Any threat from the service provider is best defended against by end-to-end
> encrypting the email - if the email is sent in plaintext then the ISP can
> simply read it.
>
> Alice can't do that herself, it's the people who send her the mail who do
> that. I wouldn't expect more than PGP / GPG type encryption, where the
> plaintext is encrypted with a symmetric cipher - perhaps EAS for new
> versions - with the key, protected by RSA encryption under a RSA public key
> the private part of which we'll call K, attached.
>
> Assuming Alice's mail is properly end-to-end encrypted she will have 100%
> plaintext protection from the ISP, although they can obtain traffic data.
>
>

I agree but due to various reasons, encrypted email is not used today
and I doubt it will be used by the majority anytime soon. Thus I
cannot use this solution at this moment.

>
>
> Alice needs a secure decryption mechanism to read her emails, and she needs
> to keep K secret. From your earlier posts, I gather that Alice does have
> such a mechanism which she uses normally, but occasionally she wants to use
> a terminal which she doesn't trust.
>
> You have suggested various ways to split the key K between the terminal and
> the ISP, but you miss one big point - no matter how you do the splitting,
> unless you have a seperate key for each email you are exposing K to a
> concert of the ISP and the terminal. Anyone getting a pair of split keys can
> decrypt _ALL_ Alice's email, past and present, until she has distributed a
> new public key.
>
>
> There is no way around that, without having a different key for each email.
>
>

Right. Do you agree that a) getting a pair of split keys requires
either the cooperation of someone working at the service provider or a
malware in the PDA; and b)the person that has a pair of split keys
needs to convice the service provider to release all the emails in
their raw format?

>
>
> Of course, each email already has a convenient seperate key anyway, all you
> have to do is decrypt the RSA block with the key in. If the RSA decryption
> is done in a secure way, eg in a pda, you expose that message to the
> terminal (though not to the ISP), _but you don't expose K_.
>
> It's quite a lot of work to enter the RSA block and the result manually, so
> perhaps you might want to get eg an iButton to do the RSA decryption for you
> - or a pda with a USB connection.
>

I like the secure coprocessor idea but its time hasnt come yet. I
cannot use it so many places. It also gives you a false sense of
security.

> The work could be shortened by using an EC version of RSA, although Alice
> would have to get her correspondents to encrypt with it.
>
> But giving out a pair of keys that allow an attacker to decrypt everything
> is lying down and inviting people to cut your throat, while offering them
> the knife.
>

I agree that this protocol has a major hole in it but you gotta accept
that it is better than what I (probably most of us) have at this
moment.

>
>
>
> It might well be better to concentrate on making the terminal secure. It is
> of course impossible, but if you boot from a CD it is very hard for someone
> to introduce malware, and mouse-driven key entry can defeat most hardware
> keyloggers (m-o-o-t does this, but it isn't available at present - you could
> try one of the Knoppix-based distro's though, they are pretty good; or even
> tinfoilhat Linux).
>

There is no way I can convice my wife to do that.

>
> Another possibility might be to bootstrap security from the secure terminal,
> but that path is fraught with dangers.

Thanks again and best wishes.
-Han