More questions about: "gpg: WARNING: message was not integrity protected"

[David Shaw]

On Sun, Apr 09, 2006 at 11:11:48PM -0300, Trevor Smith wrote:
> On 9-Apr-06, at 7:28 PM, David Shaw wrote:
> >MDC can be forced on via --force-mdc.  As Werner said, the preference
> 
> Excellent. So, the follow-up question is, should one use this option  
> for files symmetrically encrypted for long-term storage (like if  
> burned to a CD)?

You should really use MDC whenever you can.  The only time you should
not use it is when communicating with someone who can't read it.  If
you are encrypting to yourself, you can assume you can read it, of
course.

> >system will automatically handle this for public key encryption.  For
> >symmetric encryption (which has no preference system), you can use
> >--force-mdc if you want a MDC.
> 
> Can you briefly explain this "preference system"? As in, does this  
> mean a given public key may/will have a preference for some algo  
> stored in it and when my copy of GPG attempts to encrypt to that  
> public key, it uses that symmetric cipher (when possible)?

Basically, yes.

Every key has a number of preferences on it (they live on the
self-signature).  The union of these lists are taken together which
results in a list of ciphers that everyone can handle.  That is, it
doesn't matter in terms of interoperability which cipher is chosen
from this list.  To make sure that there is always a choice even if
the union is empty, in this case 3DES is used.  Finally, your
personal-cipher-preferences are consulted to pick the one from this
list that you personally like best.  MDC works similarly: each key is
consulted to see if it can handle MDC.  If all can, then MDC is used.
If AES or TWOFISH happens to be in the preferences, then it is assumed
that MDC exists even if the MDC-is-usable flag isn't set.

Have you ever bought a pizza with a number of people?  The preference
system is a bit like that.  Everyone seems to like a different topping
on the pizza but can more or less agree on something.  (Though you
can't get half one thing and half another with crypto!)

> >In an effort to increase the use of MDC, it was noted that all
> >implementations that could handle AES could also handle MDC.  Thus,
> >using any AES (or TWOFISH) turns the MDC flag on for you.
> 
> Ah, great! So there are at least two benefits of using AES over CAST5  
> then (larger keyspace and MDC turned on).

Three.  I had forgotten for a moment the larger blocksize of AES256, as
Werner pointed out.

You could turn the MDC flag on for CAST5 for yourself, of course, but
that still leaves the larger keyspace and larger blocksize that AES256
has.

> >It is, but this is not a complete answer.  Neither of you should have
> >a cipher-algo set in your gpg.conf file.  If you do, you're fighting
> >against all the automatic parts of the system.  Let GPG do what it is
> 
> Fair enough. I had set it because I was archiving some things for  
> long-term storage and discovered it was defaulting to CAST5 and  
> thought, why not use the largest keyspace I can?
> 
> But your point is taken, because I understand now that I was also  
> forcing asymmetric encryption to use AES256 as the session cipher,  
> which might cause problems.
> 
> Then again, if I send emails that I might not want people to decrypt  
> 5 or 10 years from now, would I want session ciphers to be defaulting  
> to AES256 instead of CAST5? Why is this the default?

Backwards compatibility.  CAST5 has been around it seems forever.
AES256 hasn't.

It's fine to use AES256, just don't do it with "cipher-algo AES256".
Use "personal-cipher-prefs" instead, and list the ciphers you prefer
in the order you prefer them.  Then AES256 will be used whenever it is
possible to use it (including --symmetric encryption), rather than
forcing AES256 even when the recipient won't be able to read it.

Incidentally, AES256 is really, really strong.  How strong is your
public key?  In most cases, the public key is not as strong as AES256,
so an attacker may choose to go up against the weaker public key
encryption and not attack AES256 at all.  The NIST people estimate
that you'd need a 15360-bit DSA or RSA key to match the strength of
AES256...

Nothing wrong with using AES256 anyway, of course, so long as your
public key is strong enough for your purposes.

David