[Standards-JIG] The Great Encryption Debate

Ian Paterson ian.paterson at clientside.co.uk
Tue Aug 16 21:34:36 UTC 2005

> > JEP-0116 is far easier to implement than either of the 
> > roughly equivalent combinations of JEP-0027 and PGP,
> > or RFC 3923 and S/MIME.

> Certainly, but I'm not sure if this helps your point.

My point was simply to make it clear that, considering what it does,
JEP-0116 is actually quite simple. Of course people should understand
that implementing JEP-0116 from scratch is more involved than
implementing JEP-0027 with libraries.

> There needs to be a strong reason to scrap 
> existing code and protocols

Yes. I think we've got them in this case.

> easing e2e implementation in Javascript is not one of them.  

I totally agree. In fact FYI, there are much stronger reasons than ease
of implementation for JavaScript coders to *prefer RSA* over
Diffie-Hellman for key exchange. I've exhausted all optimisations over
the last couple years and 1024-bit RSA still takes 1.20 seconds on a
2GHz CPU! D-H exponentation can't use the Chinese Remainder Theorum, so
it's four times slower. That makes all the difference, the delay becomes
unacceptable to Aunt Tillie. You can imagine that it wasn't easy for me
to accept the D-H approach, but in the end I can't justify compromising
a public standard.

I was convinced of the case for D-H in March when Peter put me in
contact with one of the IETF "crypto mafia" (he teaches crypto at MIT).
I asked him about using RSA instead of D-H. He patiently explained that
it is less secure for several reasons (no Perfect Forward Security and
"with D-H you are as secure as the best Random Number Generator in the
negotiation, [with RSA offline messages] you are vulnerable to the worst

> > I made a few minor changes to the JEP.

> Nice try, but I think this kind of defeats the point.  Simple 
> object encryption is intended to be simple.  Session encryption is 
> intended to be more capable.  Your proposal here is both complex
> and less capable.

Yes, but if you have already implemented JEP-0116, it's trivial. ;)

More seriously, for one to many signing (like groupchat and pubsub) we
do need a different protocol. Just a simple PKCS #1 (RFC 3447) signature
of canonical (or base64?) XML and a Public Key ID (digest of RSA key)
would do the trick. Optional non-repudiable authentication would also
complement JEP-0116 (for rare on-the-record legal conversations).

> Sort of.  Obviously JEP-27 has got to go, mainly because it 
> isn't modern. Extending RFC 3923 to support PGP or other
> stuff would be one answer.

We need to explore what that would involve then.

- Ian

More information about the Standards mailing list