[cryptography] preventing protocol failings

Peter Gutmann pgut001 at cs.auckland.ac.nz
Tue Jul 5 06:25:52 EDT 2011

Jon Callas <jon at callas.org> writes:

>You're writing an S/MIME system. Do you include RC2/40 or not? Why?

You're missing the point of Grigg's Law.  For the purposes of the law, RC2/40
is secure.  The problem is that you're deploying it into an environment in
which the universal default mechanism isn't secure (SMTP and HTTP).  Because
insecure mode isn't so much a communications option but "the environment", the
defender can't make too much noise for the user if they sense SMTP/HTTP
instead of PGP/SMIME or HTTPS (you'd get endless false positives), and an
attacker can always defeat the security by rolling back to the insecure
default, i.e. running their phishing site over HTTP rather than trying to get
a fake cert for HTTPS.  As Griggs Law says:

  Good Protocols bootstrap into secure mode, immediately. On first time
  starting up, the protocol goes into secure mode.

At the moment the protocols start in insecure mode and almost always run in
insecure mode.   Secure mode (whether it's AES-256 or RC2/40) is a negotiable
option, the vast majority of users don't notice when it's not present, and
apps can't warn because it'd lead to endless false positives.


More information about the cryptography mailing list