Re: secure sign & encrypt

Derek Atkins <warlord@mit.edu> Thu, 23 May 2002 20:39 UTC

Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26408 for <openpgp-archive@odin.ietf.org>; Thu, 23 May 2002 16:39:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NKTk013642 for ietf-openpgp-bks; Thu, 23 May 2002 13:29:46 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NKTiL13638 for <ietf-openpgp@imc.org>; Thu, 23 May 2002 13:29:45 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA12024; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00224; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19013; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id QAA18233; Thu, 23 May 2002 16:29:45 -0400
To: Terje Braaten <Terje.Braaten@concept.fr>
Cc: disastry@saiknes.lv, ietf-openpgp@imc.org
Subject: Re: secure sign & encrypt
References: <1F4F2D8ADFFCD411819300B0D0AA862E29ABF5@csexch.Conceptfr.net>
From: Derek Atkins <warlord@mit.edu>
Date: 23 May 2002 16:29:45 -0400
In-Reply-To: <1F4F2D8ADFFCD411819300B0D0AA862E29ABF5@csexch.Conceptfr.net>
Message-ID: <sjmr8k2zjye.fsf@gorf.mit.edu>
Lines: 101
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NKTjL13639
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 8bit

Which attacks are you trying to prevent?

I've seen different people trying to prevent different attacks here.
Pretty much every solution (except the ESE solution) protects against
some of the various attacks but not all of them.  Even better, ESE is
completely 2440-compliant, wheras all these other approaches seem to
require changes to the protocol.

I'd really like to see a clear problem statement (including a threat
model) before we change 2440 or add new packets that really only help
a subset of the problem.  Please write a concise statement about what
threat(s) you see and the problem(s) you want to solve.  Please leave
out the "how you intend to solve the problems".  We should first agree
that:

        a) a problem exists that needs to be solved, and
        b) we are actually trying to solve the right problem.

-derek

Terje Braaten <Terje.Braaten@concept.fr> writes:

> Derek Atkins <warlord@mit.edu> wrote:
> > 
> > This doesn't help.  Any recipient could re-encrypt the message and
> > change the list of encrypted recipients.
> > 
> 
> Sure it helps against the man in the middle that disastry wanted to
> protect against. Any recipient of an encrypted message can do what
> he like with it anyway, so no of course it does not help against
> any unfaithful recipient.
> 
> -- 
> Terje BrĂ¥ten
> 
> 
> > > disastry wrote:
> > > > fake pubkey encryption packets can be added
> > > > by man in the middle so that recipient thinks that 
> > message was encrypted
> > > > to him and to other preson.
> > > > 
> > > > I wrote about it here:
> > > > 
> > http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> > > 
> > > I think this can be solved by modifying
> > > Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> > > 
> > > Now it is:
> > > 
> > > version byte == 1
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > I suggest:
> > > 
> > > version byte == 2
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted Recipients packet (Tag 20)
> > >     (put it before plaintext - if it would be after it would
> > >      be difficult to find where plaintext ends, when decrypting)
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > Recipients packet
> > >   version byte == 1
> > >   number of recipients, 2 bytes (should be enough..)
> > >   number_of_recipients*20 byte list of fingerprints recipient keys
> > >     (16 byte RSA v3 key fingerprints are appended with 4 zeros
> > >      (or maybe with 4 lowest keyid bytes? I think, it's 
> > even better))
> > > 
> > > 
> > > this ensures that recipient list is intact not only for 
> > signed & encrypted messages
> > > but also for encrypted only messages.
> > > 
> > > __
> > > Disastry  http://disastry.dhs.org/
> > 
> > -- 
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        warlord@MIT.EDU                        PGP key available
> > 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available