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(_dot_)Braaten(_at_)concept(_dot_)fr> writes:
Derek Atkins <warlord(_at_)mit(_dot_)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(_at_)MIT(_dot_)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(_at_)MIT(_dot_)EDU PGP key available