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*',/((..)*)$/)