AW: Binding cryptography - a fraud-detectible alternative to key-escrow

[Eric Verheul <everheul@NGI.NL>]

On dinsdag 15 oktober 1996 22:48, Daniel Pouzzner[SMTP:douzzer@lechter.chautauqua.com] wrote:
>"Binding cryptography" does not increase the difficulty of subverting
>the key escrow facilities of a messaging system. In order to subvert
>such a system, one can either modify the messaging system (as
>described by leichter@smarts.com, for example), or nest another
>cryptosystem inside it; these techniques are not impeded through the
>introduction of "binding cryptography." There are no easier subversion
>techniques, so "binding cryptography" has zero impact on the viability
>of compulsory key escrow implementations.
I agree that binding cryptography, or any "recovery" system can be subverted
by nesting another cryptosystem into it. However, the advantages gained this way - in my
opinion are small; people wanting to do this might as well use/make their own system.

Compare this with the simple "recovery" system where users are obliged (*if* they voluntarily agree
to *use* the system) to send along a session key encrypted with a public key of a Key Recovery
Agent, and where *no* binding data is required. Then it would be trivial to convert this system
into a criminally useful one - by a simple manipulation in software - with:
- *not* having to build another cryptosystem (and its key-management) into the system;
- packets send can by no means be distinguished by third parties from "correct" ones.

As we liked the flexibility of choice in Key Recovery Agents of this system (which in our
opinion amplifies privacy properties of the scheme) we proposed binding cryptography, as
a middle between non-liberal private key escrow and the too liberal simple "recovery" system. 

>
>I am troubled because your research is misdirected, and because by
>publicizing your research you are serving to cloud what is
>fundamentally a very simple issue. In your announcement you described
>"binding cryptography" as an "alternative to key-escrow." This is
>misleading to the point of falsehood. It is key escrow with even more
>stringent constraints placed upon choice of algorithms and
>architecture.  The idea of escrowing session keys, rather than
>keypairs or passphrases themselves, is hardly new. 
We know, see above.

>The utility of key
>escrow itself is indisputable - for example, it is a clear boon when
>cryptography is used to secure documents in an institutional
>environment. However, your proposed "alternative" adds nothing of
>utility to either users or governments, and erodes the freedom of the
>software architect. I find any architectural imposition repugnant, as
>does any architect whose primary design criterion is quality.
I think that architectural problems with key-escrow systems are more
difficult than that associated with our scheme. The NRC study in fact
raises the question of key-escrow on a large scale is at all possible.

>Those of us who know better should not bicker among ourselves.
>Compulsory key escrow is plainly unethical and mathematically
>untenable. You should be ashamed for every minute you have spent
>devising stratagems by which a public less technically knowledgeable,
>but no less deserving of fundamental rights, can be duped into
>accepting compulsory key escrow thereby abdicating their privacy and
>endangering their safety.  There is no middle ground.
I respect your opinion, but I think there is a middle ground. Maybe you should be
ashamed for not realizing the future problems that arise when even the part of the
Global information superhighway that is paid for by society can be very conveniently
used by criminals to harm society. 

>
>-Daniel Pouzzner
> Software Architect
>
>