Binding cryptography - much work, little point ?
Eric_Verheul writes:
In our scheme any third party, which is probably never a TRP, can check equality of the sessionkeys send to the primary recipient (the TRP) and the second recipient (the real adressee), i.e. *without* needing secret
So could anyone anyway by asking the TRP. The TRP returns a Yes/No answer, withou disclosing the session key. Is your binding scheme motivated mainly by avoiding that workload on the TRP ? Or by the fact that everybody might prefer a different TRP ? I suspect the scheme is incomplete anyway. After skimming the web page I see that the aim is to show the same session key has been encrypted under different ElGamal pubkeys. Now who's to say those pubkeys belong to anyone ? Or is this what is meant by "such as Margaret's identity" ? You'd list the ids of the TRPs and also prove that the pubkeys used were theirs .... ? Now to the politics... E__Allen_Smith writes:
Quite simply, you've invented a system that makes censorship more possible. As a scientist, I try to avoid areas that have such negative effects
The usual Big Problems for GAK 1) What's in it for the user ? 2) What happens when the Feds recover meaningless data ? 2 does not seem to be addressed except by proposing restrictions which Eric dismisses as follows: Adam Back: >system because their stated aims are untrue: they *do* want to outlaw >non-escrowed encryption for domestic US traffic, and they *do* want to Eric Verheul: > 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. -- Peter Allan peter.allan@aeat.co.uk
Peter Allan <peter.allan@aeat.co.uk> writes:
Eric_Verheul writes:
In our scheme any third party, which is probably never a TRP, can check equality of the sessionkeys send to the primary recipient (the TRP) and the second recipient (the real adressee), i.e. *without* needing secret
So could anyone anyway by asking the TRP. The TRP returns a Yes/No answer, without disclosing the session key.
Yes, but how would you know the TRP was telling the truth? Also asking the TRP is an online protocol with respect to the TRP.
Is your binding scheme motivated mainly by avoiding that workload on the TRP ? Or by the fact that everybody might prefer a different TRP ?
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. Adam [disclaimer: I'm against GAK] -- #!/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*',/((..)*)$/)
participants (2)
-
Adam Back -
peter.allan＠aeat.co.uk