RE: RE: Binding cryptography - a fraud-detectible alternative to

To  explain the backround of "binding cryptography" once more; with
respect to (interoperable, worldwide) security in the information
society socities/governments have to achieve two tasks: 1. 
stimulating the establishment of a security structure that protects
their citizens, but which does not aid criminals. 2. Coping with the
use of encryption by criminals outside of this framework.

An inherent problem with these tasks is that different
socities/governments have different views on the matter. So to achieve
the first task you'll need a concept behind the security structure
that is flexible enough to incorporate *any* crypto policy, i.e. from
liberal (Japan) to non-liberal (France). We believe that  "binding
cryptography" is flexible enough to achieve this: a liberal crypto
policy might use no Trusted Retrieval Parties at all, while a very
non-liberal country might want one (government controlled) TRP, a
compliance check on all network traffic and a ban on other crypto.
With binding cryptography the issue on a crypto policy becomes
non-technical and politically debatable: which features does a country
want and what implementation?

Adam Back[SMTP:aba@dcs.ex.ac.uk] wrote:
> This much is the same as clipper I, just the parties have been
> renamed (TRP = split escrow key database holders, TTP = US
> government).  
No it is not. Among other things: it is a international solution, it
is based on Pub. Key. Enc. and it is flexible enough to follow
private-sector developments. It is not a key-escrow solution, as *you*
have (in principle) a very large choice in who to trust with your
communication.

Hal Finney[SMTP:hal@rain.org] wrote:
>Another flaw with schemes of this time (in terms of failing to meet
>their goals) is that they cannot detect superencryption and other
>forms of non-standard encryption of the message body proper.  All
>they can really do is verify from the outside that the same session
>key is encrypted for the two recipients (the intended recipient and
>the Government Access to Keys Party - let's not abuse the term by
>calling him a Trusted Third Party).  But they can't be sure that the
>session key is sufficient information to decrypt the message.
We offered a solution for the *first* task not for the *second*; the
point is that criminals(!) do not gain any real advantage from using
the system in that way as they - among other things - still face the
key-management problem. The above dicussions are only relevant in
countries where the use of crypto outside the structure would be
prohibited. BTW, it is by such discussions that I believe such a ban
is ineffective and in fact counterproductive.

Adam Back[SMTP:aba@dcs.ex.ac.uk] wrote:
> The paper suggests that in one plausible implementation, the
> checkers referred to could be network service providers:
>
> from the summary of the paper posted here:
>: The idea is that any third party, e.g., a network or service
>provider,
>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>: who has access to components 2, 3 and 4 (but not to any additional
>: secret information) can: : a. check whether the session keys in
>components 2 and 3 coincide; : b. not determine any information on
>the actual session key.
>
> This would allow for instance for a software only implementation of
> a madatory key escrow system.  The government in question could then
> deputize ISPs to do their mandatory GAK compliance checking for
> them. (Deputizing companies is a recent trend in law enforcment
> techniques anyway).
>
> This would allow for instance IP level encryption, with
> non-conforming encrypted packets being dropped by all ISPs in the
> country in question.  Something the Singaporeans might find useful. 
> The checking functionality could also be added to a key escrow
> enabled router.
>
> For this kind of application, binding cryptography is spot on.
Jim bell[SMTP:jimbell@pacifier.com] wrote:
> I think the biggest problem with allowing "anyone" to check the
> correctness of a key is that what is a technical possibility today,
> will become a legally-mandated requirement tomorrow.  What if
> Internet backbone companies and/or ISP's were told that they had to
> implement software check these keys, and if they discovered an
> "incorrect" escrowed key, they were legally obligated to either
> refuse to forward that message, and/or forward a copy of that
> message to someone like Spooks@NSA.gov or Thugs@DOJ.gov.    

The information society is international by nature; we want to
securely communicate with Singapore. If Singapore, a democratic
country!, has such a crypto policy that they want the above control,
then so be it. Don't blame "binding cryptography" for making that
possible, but start a dialogue with your politicians on what features
of the proposal are acceptable in your country.

Some countries seem to have the philosophy that "law-abiding" citizens
should have nothing to "hide" from their government, so should not use
encryption at all. I think that that is not acceptable. The concept
behind the third-party checking is that no "law-abiding" citizen
should have any problem that abuse - and only that - of a *voluntary*
system can be "seen" by     many parties. If and *how* checking is
done, is a matter of each society. The same concept holds for many
things in life and is well accepted. For instance that is why cars
have registration plates: if a car drives through after an accident on
a *public* road, then by-standers (third parties) can observe that. I
for one don't the information society to be the wild west, where
anything goes.

Of course, people are rightfully worried that such a checkable system
might be abused by a totalitarian regime to control their citizens.
However, as long as such a system is voluntary I see no problem. Signs
in the USA indicate (cf. the NRC study & remarks of the president)
that use of other systems will always be possible. Also, the above
discussions already showed that if such a system is voluntary, then
there are lots of way to go around it.

Adam Back[SMTP:aba@dcs.ex.ac.uk] wrote:
> 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.
Point a) can be circumvented too easily.
How do you envision point b? Sending all keys (or a selection) to the
recipient for checking is: impractical & dangerous (you want the
distance between the actual communication and the guy that can
decypher as large as possible). If you don't send keys, then abuse
will only show up during a warrant. But that abuse will show up
anyway.. So what is the use? Point c is a nice suggestion. Although I
for one have no problem that anyone can see that I comply with the
rules (..unless of course it is a non-voluntary system etc..).

Adam Back[SMTP:aba@dcs.ex.ac.uk] wrote:
> 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
Bring in to action your politicians ("the voice of the people") to let
the regulation on Trusted Retrieval Parties be as liberal as you find 
acceptable.

Peter M Allan[SMTP:peter.allan@aeat.co.uk] wrote:
>  1)  What's in it for the user ?
>  2)  What happens when the Feds recover meaningless data?
1) They get *one* system set up by governments that will make it
possible to securely communicate (and do with business) with the whole
(democratic) world. Instead of several partial systems set up by
private companies where responsibilities will be vague. I consider a
certified public key as a digital passport; setting up the structure
for passports is a task of governments. 2) Only during a warrant
policemen will see that; what then happens must every society on his
own decide. Probably nothing happens, as otherwise the investigation
will probably be to disturbed.


Best regards, Eric

Eric Verheul <everheul@rijnhaave.nl> writes:
> To  explain the backround of "binding cryptography" once more; with
> respect to (interoperable, worldwide) security in the information
> society socities/governments have to achieve two tasks: 1. 
> stimulating the establishment of a security structure that protects
> their citizens, but which does not aid criminals. 

I think market forces should cope with this just fine, without
governments.  The government `stimulation' imposed by the US
government on clipper/encryption export has cost the US software
industry billions of $ in lost trade, and the US tax payer many more
millions paying for the failed secret NSA development of clipper I.

I don't see anyone calling for the `government stimulation', quite the
opposite; the US software industry is calling for removal of export
controls.  The US software industry has been extremely uncooperative
with Clipper I, II & III.  The US public out right rejected clipper I.
Then Clinton passed it as a government standard by presidential decree
anyway.  The USG achieved some small appearance of cooperation from a
few companies they black-mailed and bribed into signing on for clipper
IV.

The USG managed to persuade the OECD to discuss key escrow, and now we
see that the USG says that it must pursue key escrow because of the
pressure from the OECD.  This is simply manipulation, and deception.

> We believe that "binding cryptography" is flexible enough to achieve
> this: a liberal crypto policy might use no Trusted Retrieval Parties
> at all, while a very non-liberal country might want one (government
> controlled) TRP, a compliance check on all network traffic and a ban
> on other crypto.

I agree, binding cryptography is an important new technology for
implementing conditional third party access to keys.  Have you applied
for patents?

> With binding cryptography the issue on a crypto policy becomes
> non-technical and politically debatable: which features does a
> country want and what implementation?

Cypherpunks vote is for none.  We vote that the civilized countries
set a good example to China and Singapore etc, by having no key
escrow, TTPs, TRPs etc.

> The concept behind the third-party checking is that no "law-abiding"
> citizen should have any problem that abuse - and only that - of a
> *voluntary* system can be "seen" by many parties. 

If its voluntary then "abuse" is not abuse, it is just not opting to
use the voluntary system.  Where is the problem?

The problem is that you appear to want to make those who do
voluntarily use the escrow systems non-interoperable with those who
don't.  (The USG wants this also, they can coerce big business into
offering escrow software only).

> If and *how* checking is done, is a matter of each society. The same
> concept holds for many things in life and is well accepted. For
> instance that is why cars have registration plates: if a car drives
> through after an accident on a *public* road, then by-standers
> (third parties) can observe that. I for one don't the information
> society to be the wild west, where anything goes.

I do.  I want the information society to be free.  I want free speech.
I can not do a hit and run with words.

If some group of prudish people do not want to hear free speech, they
can hide in enclaves, pay for a censored USENET feed, etc.

> Adam Back[SMTP:aba@dcs.ex.ac.uk] wrote:
> > 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.
> 
> Point a) can be circumvented too easily.

If the system is voluntary, circumventing it is opting not to make use
of the voluntary key escrow.  This is by definition not a crime.

> How do you envision point b? Sending all keys (or a selection) to
> the recipient for checking is: impractical & dangerous (you want the
> distance between the actual communication and the guy that can
> decypher as large as possible). 

I don't undestand your point.  You give away less by letting the
recipient check than you do by letting the government (point c), or
anyone (point d) check.

This is how I envisioned it working, RSA and IDEA encryption:

parties:

Alice:  Alices public key = PK_a, Alice's secret key = SK_a
Bob:    PK_b, SK_b
Government:    PK_g, SK_g

Alice is sending Bob the message M. 

E_b = RSA_encrypt( PK_b, left-pad_b || session-key || right-pad_b )
E_g = RSA_encrypt( PK_g, left-pad_g || session-key || right-pad_g )
encrypted-data = IDEA_encrypt( session-key, left-pad_g || right-pad_g || M )

Alice sends Bob:

C = E_b || E_g || encrypted-data

Bob can decrypt.  He can check that the government can decrypt by
repeating:

E_g = RSA_encrypt( PK_g, left-pad_g || session-key || right-pad_g )

If Alice replaces the session key in E_g with garbage, then the data
is not GAKed.  Bob will be able to detect this.  The government will
not (at least not without trying to decrypt).

> If you don't send keys, then abuse will only show up during a
> warrant.  But that abuse will show up anyway.. So what is the use?

It's voluntary, if it turns out that you did not use key escrow during
a warant, then the keys weren't escrowed.  This is what you get with a
voluntary system, people don't have to use it.

If you choose to allow the person who you are corresponding with to
verify that you are escrowing your keys, that is your business.

If you choose to allow the government also to check (option c, or d)
then that also is your business.  The whole system is voluntary.  I
don't see how you can arrange it any other way, and still claim that
it is a `voluntary' system.

> Point c is a nice suggestion. Although I for one have no problem
> that anyone can see that I comply with the rules (..unless of course
> it is a non-voluntary system etc..).

The TTP might want to be the only checker.  With c), the TRP itself can not
check compliance.  The TRP has no information until the TTP decrypts, and
hands it the key for recovery.  This means the TTP does not have to trust
the TRP not to decrypt packets, without cooperation from the TTP.

user calculates:

E_trp = ElGamal_encrypt( PK_trp, session-key )

and sends:

E_ttp = ElGamal_encrypt( PK_ttp, random-pad || E_trp )
E_user = ElGamal_encrypt( PK_user, session-key )

(random-pad to avoid any further binding checks)

now TTP can check, by decrypting E_ttp to get E_trp, and using the
normal binding check that E_trp and E_user are encryptions of the same
session key.  The TTP sends TRP E_trp, and TRP can decrypts it, if the
request satisfies it's policies.

If the TTP further wishes that the TRP does not see the session key,
even when the TTP has cooperated with the TRP to get the key, you
could arrange key splitting:

user calculates:

session-key = session-A XOR session-B
E_trpa = ElGamal_encrypt( PK_trp, session-A )

user sends:

E_ttpa = ElGamal_encrypt( PK_ttp, random-pad || E_trpa )
E_ttpb = ElGamal_encrypt( PK_ttp, session-B )
E_usera = ElGamal_encrypt( PK_user, session-A )
E_userb = ElGamal_encrypt( PK_user, session-B )

recipient calculates:

session-A = ElGamal_decrypt( SK_usera, E_usera) 
session-B = ElGamal_decrypt( SK_userb, E_userb) 
session-key = session-A XOR session-B

TTP checks:

check = bind( E_usera, E_trpa ) AND bind( E_ttpb, E_userb )
session-A = ElGamal_decrypt( SK_ttp, E_ttpb) 

TRP at TTP's request:

session-B = ElGamal_decrypt( SK_trp, Etrp )

Then TTP calculates:

session-key = session-A XOR session-B

Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

On Sun, 13 Oct 1996 everheul@mail.rijnhaave.nl wrote:

> Of course, people are rightfully worried that such a checkable system
> might be abused by a totalitarian regime to control their citizens.
> However, as long as such a system is voluntary I see no problem. Signs
> in the USA indicate (cf. the NRC study & remarks of the president)
> that use of other systems will always be possible.

I believe this paragraph is alone absolute proof that forums which
permit only discussion of technical details, and not the politics thereof,
are counterproductive.

The author above has so little concept of the nature of the American
Political system, and indeed the political systems which will seek to
regulate cryptography in democratic governments all over the world, as to
be outright dangerous.

--
I hate lightning - finger for public key - Vote Monarchist
unicorn@schloss.li