incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 119090] Default Encryption Fails for Down-Level Implementations
Date Fri, 23 Mar 2012 05:58:59 GMT

--- Comment #17 from orcmid <> 2012-03-23 05:58:59 UTC ---
(In reply to comment #6)
> I think this is a security versus interop trade-off.
> It is interesting to note that the author of the Blowfish algorithm actually
> recommends not to use it anymore:
> He wrote TwoFish to replace Blowfish. Twofish was submitted in the competition
> to replace the older DES standard.  AES was picked as the winner of that
> competition, not Twofish.  So from a security standpoint, our default of AES is
> the best choice.

That 2007 interview with Schneier is interesting, but I think Schneier's
appraisal is more nuanced, so I hit the books.

First, why would Schneier not recommend Blowfish any longer?  Two reasons: the
block size is too small and it is not approved by the U.S. Government.  64 bits
is not very good and even 128 isn't desirable any longer.  This is why AES256
tends to be chosen, even though it has been thought that AES128 may actually be
the superior of the three sizes standardized. 

Why does block size matter?  Well, once some sort of chaining has to be added,
there is increased risk of information leakage.  The more blocks it takes, the
more likely the risk of information leakage and vulnerability to what is called
a collision attack.  There are also important kinds of tampering available when
chaining is employed.  (It is odd, in that context, that ODF basically produces
8-bit CFB blocks from what start out to be 64-bit blocks.  Every cycle, 56 bits
are discarded. I suspect this is why CFB is no longer mentioned in Schneier
texts.  Now, the information leakage that is worrisome is not quite so
applicable to ODF documents, because the plaintext is a binary compression. 
But it is nice not to have it.  (If of those vulnerable blocks has a known
plaintext, the situation can go badly more quickly.)

Back to AES.  Here are some considered words about the supposed higher security
of AES:

In "Practical Cryptography," Niels Ferguson and Bruce Schneier, 2003, pp.56,

  "We have one criticism of AES: we don't quite trust the security. ...
  "In the end, everyone will use AES because it is the U.S. Government
standard.  We even advise people to use it, because it *is* the standard and
using the standard avoids lots of discussions and problems.  Even if AES is
ever broken, nobody can fault you for having chosen the standard cipher.  But
the very aggressive design coupled with the clean algebraic structure just
makes us feel very uneasy."

In "Cryptography Engineering," Neils Ferguson, Bruce Schneier, and Tadayoshi
Kohno, 2010, p.59:
 "3.5.6 Which Block Cipher Should I Choose?
 "The recent cryptanalytic advances against AES make this a tough choice. 
Despite these cryptographic advances, AES is still what we recommend.  It is
fast.  All known attacks are theoretical, not practical.  Even though AES is
now broken academically, these breaks do not imply a significant security
degradation of real systems in practice.  It is also the official standard,
sanctioned by the U.S. government.  And everybody is using it.  They used to
say 'Nobody gets fired for buying IBM.'  Similarly, nobody will fire you for
choosing AES.
 "AES has other advantages.  It is relatively easy to use and implement.  All
cryptographic libraries support it, and customers like it, because it is 'the
standard.' "

It is not about superior security, although the larger block size is an
important consideration.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

View raw message