David Leon Gil <coruus(_at_)gmail(_dot_)com> writes:
On Monday, March 16, 2015, Derek Atkins <warlord(_at_)mit(_dot_)edu> wrote:
[snip]
Having implemented it myself, I disagree completely. It is absolutely
possible to create a modular implementation. See my Usenix Security
Talk on the PGP Message Processing Pipeline from.... 1996??
Well, first: You're Derek Atkins. Not everyone is as good of a coder.
*blush*
Second: It is hard to *prove* modularity, because of how complicated the
semantics are. (I have been trying, off-and-on, using Frama-C, for a while.)
Yes, the structure is complicated (my parser state machine had something
like 150-200 states). But the processing itself is completely modular.
You just need concepts like split and join along the pipeline to handle
it. Proof by existance?
[snip]
>> Protocol modularity is not evil.
>
> Modularity is neutral. "Agility", as folks like to call it, is evil.
Well, it's a damn good thing we've had agility otherwise we'd have been
stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe
DSA/Elgamal.
No: The reason there hasn't been any urgency to fix things like the CFB mode
problems, or the MDC, is that the current standard is too flexible.
I don't agree with this statement. It wasn't flexibility that stopped
changing CFB, it was that CTR mode was relatively new when the group was
working on 4880 (I'm not sure it even existed when we did 2440). And
compatibility was always (generally) paramount. I.e., if it ain't
completely broke let's not fix it.. and where it is broke, let's fix it
in the most compatible way.
Were I do start from scratch today then yes, I'd just use GCM. We could
certainly add a GCM mode and a preference to specify support for it.
But for interop I don't think we could drop CFB support completely from
implementations.
I'll also point out that CFB vs "something else" (i.e., "mode agility")
is completely orthogonal to algorithm agility. OpenPGP does NOT have
decent mode agility; we would need to add a new packet type for that.
I hate to use TLS as an exemplar of anything, but they have done a much better
job in this regard recently.
Where it is easy to provide flexibility, it is rarely useful. Where it is
useful, it is rarely feasible to provide. (E.g., a parameter to choose SIV,
encrypt-then-MAC, or robust AE.)
It's easy to add it if you think about it ahead of time (and put in the
parameterization). It's harder to add it after-the-fact. This is true
in both TLS and OpenPGP.
-derek
--
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp