Jon Callas <jon(_at_)pgp(_dot_)com> writes:
At 11:53 PM 6/25/98 +0100, Adam Back wrote:
- Gary Howlands attack which can undetectably garble unsigned
encrypted messages ... has this was been fixed?
If not perhaps we could either fix it (include optional? unsigned
digest inside message) or have wording added to highlight that
unsigned encrypted messages offer little protection against garbling.
As I remember the consensus on this one, garbling is a problem on all
messaging systems unless you have a signature or a MAC.
Yes, that's why most of them have MACs or signatures :-) I countered
this point last time this was discussed with the example of SSL, which
uses MACs to prevent against garbling and truncation attacks. It is a
known problem with a known solution. I think it is actually quite a
bad problem. So why not fix it?
There are very good reasons not to sign all messages, whilst still
requiring confidentiality:
a) not having to enter ones passphrase to send a message (each use
adds to risk of exposure, and may be using in an untrusted environment)
b) automated systems which are running as processes without user
input, and you don't want the private signing key in memory (eg
backup daemons, encrypting mail forwarders, etc)
c) not wanting to have transferable non-repudiable signatures on all
your email. (non-transferable sigs can reduce this problem...)
Adding in a MAC or digest to an encrypted packet breaks backwards
compatibility.
No, disagree.
We can add MACs as a fix defined to be only available where public
keys indicate open-pgp 1.0. That means it will not be created in
messages sent to pre open-pgp 1.0 implementations, and therefore there
is no backwards compatibility problem.
I would suggest either HMAC, defined over the same set of hashes
availble for signatures, keyed with the symmetric key used for
encryption, or more simply just an existing digest packet as used
inside signatures. (It only makes sense to add MACs or digests to
encrypted messages, and an encrypted digest packet is a form of keyed
MAC).
I thought the consensus was that with 1.X we would look at adding
some form of integrity check, perhaps with a new type of encrypted
data packet.
The reason I am keen on adding a MAC is a) it is broken (badly in my
view) and needs fixing; b) it is easy to fix; c) it does not affect
backwards compatibility.
I prefer a digest packet inside the encrypted envelope (at the end of
the plaintext to aid one-pass processing), rather than a MAC for
reasons of simplicity (people already have code to compute and emit
digest packets for the available hashes). It is probably easiest to
define the digest packet as a signature packet. (This can then borrow
the one pass packets etc from existing signature parts).
So changes required would be:
- define a digest packet in the same framework as signature packets
emit the unsigned digest packet which would otherwise have been
signed
- use the same mechanism used to allow one pass processing of
signatures to allow one pass processing of digest packets.
- define that the digest packet can be optionally skipped if the
message is signed
Adam