Re: AW: Binding cryptography - a fraud-detectible alternative to key-esc

[Adam Back <aba@dcs.ex.ac.uk>]

Eric Verheul <everheul@NGI.NL> writes on cpunks:
> Adam Back <aba@dcs.ex.ac.uk> writes:
> >[...]Also
> >the proposal (and other proposals which escrow session keys) doesn't
> >really provide any guarantees of protection from LE abuse, as such,
> >because they can decrypt all of the escrowed session keys with their
> >own private key
>
> No. In the scheme Law Enforcement (that is your LE, right?) agencies
> are never handed over the private keys of Trusted Retrieval Parties
> (TRPs), only the session keys.

My assumption was that a TRP is a government front.  (All of the
proposed clipper I escrow agents have been major US defense
contractors/government agencies, in addition the clipper I documents
hinted that the NSA would have a complete copy of the key database, in
any case).  I also fear that the government set regulations covering
TRPs would not be balanced in the favour of the public.  Your paper
did discuss this in the context of governments.  The US government is
the government which has explored key escrow the furthest, and this is
really why people are discussing your TTPs and TRPs in this context.

> So for each sessionkey LEs will have to go to a TRP. 

This much is the same as clipper I, just the parties have been renamed
(TRP = split escrow key database holders, TTP = US government).  The
novel part of your paper to me is your technical proposal to prevent
Blaze style spoofing of escrowed session keys.  Clipper I could have
prevented Blaze, if they had used a larger cryptographic checksum
(only 16 bits were used) to verify conformance.  However they were
relying on tamper proof hardware, your protocol works for software.

As your paper describes, your system allows anyone to check the
correctness of the escrowed session key.  Have you considered
modifying it so that the only person who can check is the owner of a
designated private key of a public/private key pair?  This would allow
say for the TTP to check correctness, and not the TRP, nor the public.
I'm not sure of the usefulness of this, but it allows you to select
from the full spectrum according to requirements:

a) no one can check, PGP second recipient (Carl Ellison, Bill Stewart)
b) recipient only can check (my suggestion)
c) holder(s) of designated keys can check
d) anyone can check (your proposal)

c) should be easy to acheive: restrict d) by having the sender encrypt
the escrowed session key a second time to this public key.

Something technical related to this discussion is the idea of using
forward secret protocols for email.  This goes even further away from
allowing others access to your data, and is another option to add to
list above, probably before a).  

The current situation is that with PGP at least, the recipient can be
coerced by governments (TTPs) into decrypting the email, if he still
has the private key, as PGP keys are commonly long term having the key
is likely.  In this sense you are `escrowing' the messge with the
recipient.

Using Diffie-Hellman (or a less interactive Diffie-Hellman, by using
hashes of the original Diffie-Hellman session key for subsequent
emails, an improvement over my original proposal for a non interactive
forward secrecy protocol suggested by Hal Finney) ensures that neither
you nor the recipient can be made to decrypt a wire-tapped message
unless they take specific actions to ensure this possibility.

This also allows finer control, as almost nothing is provided in terms
of recovery, and any message recovery for other parties or for
yourself can be added as required.  I would suggest adding any
recovery by archiving the data locally with encryption keys according
to the users backup, or recovery requirements.  This way any
wire-tappers get to come and ask for the data, and then ask for the
keys (neither of which the private user has any obligation to keep,
some businesses may have different legal obligations, contractual
agreements or recovery requirements, and they are free to archive this
accordingly, including taking wire-tap enabling steps such as
escrowing session keys with the message, if they wish).

> Moreover, the choice of TRPs should be large, so the idea is that
> you can always pick one you trust. Or set up your own, for that
> matter...

OK, now if this was the case, that allowing others access to your keys
is strongly voluntary, and that you can select from key holders, and
the TRPs have no externally imposed regulation I don't have a problem.

The reason cypherpunks get touchy about `key escrow' is that we now
know that, at least in the case of the US, the intention all along was
for eventual outlawing of non-escrowed crypto.  FOIA documents
obtained by the EFF indicated that this was the plan all along.  More
recently FBI director Freeh has been quoted as saying something like
`If [clipper variants] are not succesful at catching criminals we will
consider outlawing non-escrowed crytpo'.  (This is just so bogus --
any criminal would be a complete fool to use the escrowed crypto, so
the `are not succesful at catching criminals' is almost guaranteed to
come true.  Further, even if they _do_ outlaw non-escrowed crypto,
criminals won't be using it.)  The current angle the USG plans with
the clipper variants, is to achieve as much as possible in the
direction of outlawing non-escrowed crypto by coercing companies to
sell only escrowed crypto, and so acheive their aims by de facto
standard.

> In your suggestion checking can only be done with secret information
> (you need the secret key of the primary recipient).

I saw this as an advantage, politically I view it as preferable that
the only person who needs to know whether you are talking `on the
record' is the person you are communicating with.  (In the context of
a voluntary system, with this as a stated contractual or participatory
mutual agreement).

> Also, "random padding" information of the second recipient is very
> secret as well, just compare the results Don Coppersmith presented
> on Eurocrypt97: if you know the enough padding you know it all. So
> for instance sending along the padding info along will make any
> key-escrow superflous (-;

The padding was to be encrypted for the primary recipient along with
the message, not in the clear.  The primary recipient can already
decrypt, so having the padding adds nothing for him.

I suggested this in response to someone discussing feasibility of
software key escrow for Clipper II.  Clipper II had requirements that
the software not interoperate without modification with non-escrowed
versions.  This fulfills that requirement.

Another comment on your proposal is that although it allows anyone to
verify, it is not generally the case that anyone (other than the
recipient) is in a position to verify.  In many jurisdictions it is
illegal to intercept other peoples email.

> >As GAK is (stated to be) voluntary, surely the only person who has any
> >business knowing whether the message is honestly GAKked is the
> >recipient.  After all you can double encrypt or not use GAK at your
> >option, so this seems to lose nothing for the GAKkers.
> >
> >The description of the paper also says nothing about trust worthiness
> >of the TTPs, from the public's perspective.
>
> As far as we are concerned, anybody - willing to follow regulating -
> can set up his own TRP.

You suggested that even if the system was voluntary, and anyone could
become a TRP, governments would have regulations granting only those
they deemed suitable the right to operate a TRP!

If this is voluntary, truly, I don't see the need for government
regulation.  Surely I personally can start a TRP, and ignore the
governemnt regulations, GAK is voluntary right, and my system isn't
GAK, this is a private contract between me and my clients, not a
government approved TRP.  Can I operate non government approved TRPs?
(I'm having a hard time thinking of any individuals who would use it
even if I did!)

> > (Not that I,
> >or anyone else would want to use GAK still, but it would be a gesture
> >of good will on the part of the GAKkers, and would show intentions not
> >to misuse the system.  I suggest that they would never agree to such a
> >system because their stated aims are untrue: they *do* want to outlaw
> >non-escrowed encryption for domestic US traffic, and they *do* want to
> >decrypt without warrants, and without public audit.  Export control
> >and temporarily `voluntary' GAK is a means, not an end.)

> Who is they, governments as a whole? If you simplify discussions in
> this way, I might as well say: "you guys only want to help
> criminals". I understand your fears, but don't exaggerate.

The US government at least, has demonstrated all of the above.

I don't trust governments, because governments have repeatedly
demonstrated that they are not trustworthy.  I live in the UK,
mistrust of government is not a US only thing.

Adam
--
#!/bin/perl -sisN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsjxII*op"
$/=unpack('H*',<>);print pack('C*',split('\D+',`echo 16i\U$k"SK$/SM$n\E$^I|dc`))