Re: secure sign & encrypt

[Derek Atkins <warlord@xxxxxxx>]

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@xxxxxxxxxx> writes:

> Derek Atkins <warlord@xxxxxxx> 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@xxxxxxx                        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@xxxxxxx                        PGP key available