ࡱ> 9 \bjbj 7Dym!l"&%%%8(&<d&<V&:&&&& *T`*|*$ 3-*****;BB&&A4;;;*&B^&&;*; ;>.N&& eyr6 %8\N@,uHK;K;BBBBNon-repudiation despite Encryption Marc Fischlin  HYPERLINK "mailto:mfischlin@cs.ucsd.edu" mfischlin@cs.ucsd.edu Department of Computer Science & Engineering, University of California, San Diego Ulrich Pordesch Fraunhofer Gesellschaft  HYPERLINK "mailto:ulrich.pordesch@zv.fraunhofer.de" ulrich.pordesch@zv.fraunhofer.de with support from Brian Hunter  HYPERLINK "mailto:brianhunter@canada.com" brianhunter@canada.com Fraunhofer SIT. Electronic documents should be non-reputable through signatures and time-stamps and their privacy should be attained via encryption. However, signing and time-stamping encrypted documents does have its problems, since encryption is not necessarily unique. This article discusses the requirements needed in order to maintain the evidence value despite encryption. Furthermore, it shows a practical solution using hybrid encryption based on the Cryptographic Message Standard (CMS). 1. Introduction The non-repudiation of authorship, integrity or the time of existence of electronic documents must often be proven in the electronic legal world. Besides ensuring the evidence value of documents, the confidentiality must often be safeguarded. Both of these goals should be achieved through electronic signatures, time-stamps and encryption. Generally, documents are first signed and then encrypted. After decryption, one finds a signed message, whose signatures and time-stamps can be verified. However, sometimes there is a need to reverse this process, namely, the signing and time-stamping of encrypted data. An example of this is the archiving of signed documents. A customer, e.g. a hospital, wants to send encrypted documents, so that the archive provider cannot read them in clear text. Furthermore, one wishes to avoid the release of all patient and doctor details, when the archive providers disks are seized due to a legal warrant. At the same time, the archive provider should be able to archive time-stamp the documents, and if necessary, renew them, in order to maintain the evidence value of the signatures [BPRS_2002]. Decryption of the documents before archive time-stamping would defeat the purpose of encryption and would require considerable effort. Another example is a postmaster, where incoming and outgoing documents are attested via signatures, but the content should not be readable. Unfortunately, the signing and time-stamping of encrypted data is problematic: The evidence that encrypted documents have not been changed, were created by a given author or existed at a given time point, is not necessarily an evidence of the authorship, integrity or timely existence of the corresponding unencrypted document. It could be managed by maliciously choosing a suitable key that other documents, besides the originally encrypted document, be decrypted. Therefore, techniques must be used that ensure both the non-repudiation and the confidentiality at the same time. 2. General Requirements In order to be able to formulate concrete requirements for encryption methods, the processes of encrypting, signing and time-stamping will be abstractly laid out in the following: It is assumed that a readable document D is encrypted (encrypted document, eD) by a user. The data will then be extended by adding, e.g. the intended recipient, and finally sent or stored (stored document, sD). This stored document would then be signed or time-stamped. Desired are methods that fulfil the following requirements: Provable Uniqueness: If a third party (e.g. a judge) is given D and sD, then he must be able to verify that sD corresponds to D and that there exists no other D* that also corresponds to sD. In particular, the proof of existence of D at a given time must follow from the proven existence (via signatures or time-stamps) of sD at this time point. To ensure the applicability to long-term archiving for example, this unique correspondence should be independent of cryptographic assumptions (such as the collision resistance of hash functions). Decryption Possibility: Intended recipients must be able to (with help of a secret, e.g. a private key) later derive (decrypt) D from sD. Preservation of the Confidentiality: If additional data is saved with the stored document sD, e.g. data to prove the uniqueness, then this should not help, or at most negligibly help, an attacker break the encryption. Efficiency: Decryption and the required steps to prove the uniqueness must be able to be efficiently evaluated, in particular, they must not require an exponential effort. In the following, current encryption methods will be investigated based on their fulfilment of these requirements. Then a practical solution will be introduced that is based on common methods, namely RSA and DES. Finally, the requirements of the realisation of additional verification components will be discussed. 3. Analysis of the Methods Today in general, encryption is a two-step process: Step 1: The document is initially encrypted using a content encryption key (cek) and a symmetric encryption method. Step 2: The content encryption key (cek) is then itself encrypted, using another key. This results in an encrypted content encryption key (ecek). This encryption of cek can use either an asymmetric method (Public key encryption), or a symmetric method where the key is, e.g., derived from a password. The so-called hybrid methods fall under this two-step process, namely, the methods composed of a Private key and a Public key method. In this case, only the short key, cek, is encrypted using the less efficient Public key method and the, in general, longer document is encrypted using the fast symmetric method. For the decryption, cek will be first reconstructed from ecek, with the help of a secret (e.g. the password or the private key of the public key method). Then the unencrypted document can be obtained using cek. So that not only the stored document but also the resulting unencrypted document are non-reputable, both of the used encryption methods, and their parameters and keys, must exhibit certain security properties. These properties must be separately verified in order to prove the uniqueness. This will be described in the following for the two-step encryption method. Step 2 differentiates itself according to the requirements of the manner in which the correspondence between cek and ecek should be performed, i.e. ecek can be decrypted and compared with a purported cek (Decoding), or a given cek can be encrypted and compared with ecek (Re-encoding). Content-Encryption When the document D is encrypted via a symmetric encryption component, symEnc, a random value r is needed in addition to the secret symmetric key, cek. Mathematically, all symmetric encryption algorithms are a function of these three parameters, cek, r and D: C = symEnc(cek, r, D) The random value r is the empty bitstring in deterministic methods. Otherwise, as a general rule, it consists of only a few bits, e.g. the 64 bit Initial Vector (IV) in the DES-CBC method. It is generally not inputted by the user, rather produced by the encryption program as needed, e.g. via a local pseudo number generator. Admittedly, a cheater could modify the program so that he could freely choose r. In contrast, current decryption algorithms, symDec, operate deterministically, that is, they reproduce the unencrypted document from the cipher text with the help of the key cek. This process does not require that the random value be inputted. In order that this first step of the two-step process is unique, one must be able to later determine the uniqueness of the document, when cek is given. Consequently, the following properties are necessary: Given a key cek and a symmetric method (symEnc, symDec), then one can efficiently prove that at most one document can be reconstructed from a given value C. That is, there is at most one D where D=symDec(cek, C). Given a valid key cek and a valid cipher text C = symEnc (cek, r, D), then the document D will always be decoded using symDec. This property must be verifiable in an open and efficient manner. The requirement on the efficiency rules out costly determination methods (e.g. exhaustive search with exponential cost). The condition for an open verification allows for a third party to verify the data. The verification generally includes checking the validity of the key cek, that is, whether the bit length of cek is in an allowable range and whether, in the case of DES, the parity bits are correct etc. For current methods, this is easy to check. Current encryption algorithms actually fulfil the above properties. However, this is only true when the secret key cek is fixed: Since for most methods, one can in general find another document D* for another valid key cek* `" cek (and random value r*), so that: symEnc (cek, r, D) = C = symEnc (cek*, r*, D*) The question of if and how many such collisions (D, D*) exist, and whether such documents are meaningful, is difficult to answer. Generally, it can be determined that with current methods the number of such possibilities correspond to the number of possible valid keys. Thus, unlike hash collisions, such collisions are finite, albeit possibly very large. Even though collisions for meaningful documents appear to be unlikely, we are not aware of any results about such collisions for specific symmetric methods. Thus, it remains open, whether current or future methods can or will eliminate such attacks. The existence of meaningful collisions must not be completely ignored, in particular, when it comes to the legal question of non-repudiation. One may come up with the idea of another way to cheat by choosing the same key, cek*=cek, but using a different random value r* symEnc (cek, r, D) = C = symEnc (cek, r*, D*) to find a collision for another Document D*. This would imply that the decryption, using symDec, was not unique, since the Ciphertext C would be produced from differing documents but the same key cek. Hence, to eliminate this possibility of cheating, symmetric methods must support unique decryption, which is indeed the case for classical methods. To summarise, to guarantee the uniqueness of a Document D when using current methods (that guarantee a unique decryption), it is necessary and sufficient that the chosen encryption method in step two and the key cek are unambiguous. This means that these inputs must also be stored (in Step 2), in addition to the document itself. An alternative would be to require that the Ciphertext C uniquely determines the key cek, so that this attack of choosing another key is eliminated. However, current methods do not have this property. Asymmetric encryption with Re-encoding In this variant of the second step, the encryption of the Content-Encryption-Key, cek is encrypted using an asymmetric encryption method, along with a public key pk and random value s: ecek = asymEnc ( pk, s, cek ) The description of the method asymEnc, the public key pk, as well as the encrypted content encryption key ecek will then be stored. The evidence that ecek really corresponds to cek can always be produced, when the verifier decrypts (Decoding) ecek or when he encrypts cek again and compares the result with ecek (Re-encoding). We initially consider the case of re-encoding. In the case of re-encoding, the demonstrator must store the random value s separately. The key cek will be later calculated from ecek with the help of the private key sk (corresponding to pk), otherwise cek must also be separately stored. As evidence, cek and the random value s will be later given to the verifier. The verifier can then re-encode cek using the stored description of asymEnc, pk and s. That is, he calculates asymEnc (pk, s, cek) and compares its result with the stored value ecek. To guarantee the uniqueness of cek, the following requirements must be fulfilled: Given pk and an asymmtric method asymEnc, one can efficiently check that at most one cek may be reconstructed from the given value ecek. That is, there exists at most one cek, so that ecek = asymEnc (pk, s, cek). The possibilities of cheating are initially the same as those with symmetric encryption. Therefore, it cannot be ruled out, that there exists pk*, s* and cek*, such that ecek = asymEnc (pk*, s*, cek*). This cheat can be prevented by specifying, i.e. storing, pk, which can be then openly verified. It is noted that an attack, via the manipulation of the random value s, is not possible, as in current asymmetric methods, since this would imply that the decryption is not unique. There is, however, a further cheat, which is possible through the choice of a suitable key. If, for example, a cheater using RSA chooses a valid modulo N with exponent e, such that e is not relatively prime to ((N)=(p-1)(q-1), then the RSA-function x ( xe mod N is ambiguous, that is, every value in the image is a map from multiple preimages. Through the choice of e=2, there exists for example 4 preimages. If one allows any exponent, then an attacker can even choose an exponent so that the number of preimages for this RSA-parameter approaches the order of N. That is, for current security parameters, the number of preimages lies in the magnitude of 21000. Special exponents, such as e=2, are admittedly easy to detect and avoid. However, without knowledge of the private key, it is in general not efficiently verifiable whether e is relatively prime to ((N), and thus that the RSA-function is one-to-one. For a given Ciphertext and encryption method, the number of collisions and the possibility for a cheater to find such collisions using a suitable choice of the public key is method dependent. The number is obviously finite, while the quality of the collisions (i.e. whether meaningful keys cek, cek* derive meaningful documents D, D* using the symmetric method symEnc) through the combination of symEnc and asymEnc is even more difficult to predict. This depends on, among other things, the formatting rules of the method. The RSA PKCS#1 v2.1 Padding noticeably constricts the number of possible preimages, so that even for maliciously chosen parameters, the number of meaningful preimages is substantially less than for example 21000. However, in this area, there is also no related work known to us. Conclusion: In order to guarantee the uniqueness, pk and the description of asymEnc must be stored and the public key must be suitable. This requires additional validation steps that, in particular, must be efficient and open (i.e. without knowledge of the private key). Asymmetric encryption with Decoding The storage phase of this approach is identical to the re-encoding approach. However, as evidence, the private key sk will also be transferred. The receiver then decodes ecek to obtain the Content-Encryption-Key, cek. A disadvantage of this approach is that the confidentiality is jeopordised of all the stored documents that used the corresponding public key, when the document owner hands over his private key. On the other hand, the possibility of cheating is significantly reduced by the hand-over of the private key. Using RSA as an example, after obtaining the private key (i.e. the factorisation of N or equivalently decrypting exponent d), one can efficiently verify that the key is a proper RSA key. This is achieved by verifying the primality of p,q, and checking that N=pq and that e is relatively prime to (p-1)(q-1). These steps can be efficiently carried out. In general, the requirements on uniqueness are: Given sk, pk and the description of the encryption method (asymEnc, asymDec), one can efficiently verify that there is at most one key cek that can be reconstructed from a given value ecek. That is, there exists at most one cek with cek = asymDec (sk, pk, ecek). cek will always be decoded from a valid key pair (sk,pk) and a valid Ciphertext ecek = asymEnc (pk, s, cek). Although these requirements are efficiently verifiable for RSA, as already mentioned, this cannot be simply implied for other encryption methods in general. In conclusion, additional verification steps are also necessary by the decoding approach. Which steps these are, is dependent on the method; the general requirements were formulated above and illustrated for the RSA case. Password-based Encryption In the case of password based encryption, the Content-Encryption-Key cek is encrypted with the help of a symmetric method. For this purpose, the password pw is initially mapped to a Document-Key dk, using a Key-Derivation-Function KDF (with public parameter p). The Document-Key is then used to encrypt cek using the symmetric method symEnc, whereby the same method symEnc can be used for symEnc. dk = KDF ( pw, p ) ecek = symEnc ( dk, s, cek ) For decryption, only the password pw is needed. Using KDF, the verifier then calculates the Document-Key dk and decrypts ecek using symDec. In this approach, the password pw should uniquely map to the content encryption key: Given algorithms symEnc, symDec and KDF (and its public parameter p), one can efficiently verify that at most one key can be reconstructed from a given value ecek. That is, there exists at most one cek with cek = symDec( dk , ecek ), whereby dk = KDF ( pw, p ). cek will always be decoded from a valid password pw and a valid Ciphertext ecek = symEnc( dk, cek, s ) with dk = KDF ( pw, p ). Thus, the requirements here on uniqueness, as in the case of Content-Encryption, are essentially reduced to the uniqueness of the method symEnc (see above). Current symmetric methods do not guarantee this uniqueness and appropriate constructions, which fulfil this requirement, are very costly [CMR_1998, F_1999]. Password based encryption is thus dropped insofar as a de facto method. Special Problem: Multiple Recipients There is an additional problem to consider, if a message is to be encrypted (using the described hybrid method) for multiple recipients. A cheater could intentionally encrypt differing ceks for the different recipients. Then, the same encrypted document could correspond to differing decrypted documents, depending on which pk for re-encoding or which sk for decoding was used. This ambiguity is irrelevant for the proof of timely existence of data (such as for signature renewal via archive time-stamping of encrypted documents). The same stored message proves, at the same time, the timely existence of multiple decrypted documents. The problem with the ambiguity arises when the Content of the Declaration (in electronic form) needs to be established. In this case, differing contents could be presented and they could lead to difficulties in deciding which content should be accepted [Pord_2003]. In order to avoid this possibility, one must decode (or re-encode) the Document-Encryption-Key for all the recipients and verify that they are consistent. 4. Solutions In this section, we suggest some solutions that fulfil the above requirements. These solutions achieve the same efficiency level as compared to current encryption methods, which do not hold the uniqueness property. We consider solutions based on the Cryptographic Message Syntax (CMS, RFC 3369) and of the type enveloped data with encrypted data. According to CMS, the sender can send an encrypted document (using cek) within a cryptographic message of type EnvelopedData. The description of the encryption method symEnc is contained within this structure, in the form of the unique ContentEncryptionAlgorithmIdentifier. The value ecek and the description of the algorithm asymEnc are added to a RecipientInfo element. In addition to ecek, the certificate, the public key pk and the method asymEnc can be added to the element KeyEncryptionAlgorithmIdentifier, in particular using the elements RecipientIdentifier and KeyEncryptionAlgorithmIdentifier. Symmetric Encryption As already mentioned, all conventional symmetric algorithms fulfil the property of uniqueness for documents with a determined Content-Encryption-Key cek. In particular, the following fulfil this property, in conjunction with a usable method in CMS for Content Encryption: Triple-DES CBC, see RFC 3370, Section 5.1, as well as references there RC2 CBC, see RFC 3370, Section 5.2, as well as references there IDEA CBC, see RFC 3058 The Modes of Operation for AES are still being specified at the moment. It is expected that AES will also be a suitable encryption algorithm for unique decoding. Therefore, in the context of CMS, there exists a multitude of suitable and usable methods that fulfil the uniqueness property. Re-encoding We describe two solutions that add the uniqueness property to the RSA encryption method RSA-PKCS#1 v2.1. One solution is based on using a key pair of a trusted third party and is in principle portable to other encryption methods. The other, RSA specific, solution uses large encryption exponents. In order to eliminate the ambiguity within RSA-PKCS#1 v2.1 (including its specified padding), it is sufficient to make the mapping x ( xe mod N one-to-one. To achieve this, the exponent e, within the public key, must simply be chosen such that it is relatively prime to modulo N. The proof that this is the case can be shown in a variety of ways: The signer uses an RSA key whose security properties were confirmed by a trusted third party. For example, his RSA key pair could be created by a trustworthy, accredited Certificate Authority (CA). Another alternative is the use of a public key from a trusted third party, who guarantees the security properties of the key. The signer encrypts cek with his own public key and then also encrypts cek with the public key of the trusted third party and adds this ecek to the structure (parallel encryption). For decryption, he uses his own key, but for evidence of existence, he does re-encoding using the key of the trusted third party, whose certificate is contained within Recipient-Info. The value of cek is binding, since it was derived through the method of re-encoding, using the key of the trusted third party. This solution is elegant inasmuch that the certification of encryption keys by third parties is avoided. However, the disadvantage is that the owner of the auxiliary key (i.e. trusted third party) could possibly read the document. For the RSA method, there exists a special alternative that avoids the certification of the keys. The signer chooses a key, whose exponent e is so chosen that it is prime and bit length(e)>bit length(N) (and other known security requirements are respected in the choice of the exponent). With this type of exponent, the recipient can easily compare the bit lengths and can then test the primality of e via quick, probabilistic standard methods (e.g. Miller-Rabin test) with a small chosen degree of error or via slower, error-free tests [AKS_2002]. These tests guarantee the uniqueness property of the RSA mapping, without being dependent upon the choice of N [H_1999]. In this manner, the data is protected from third parties. Only the efficiency is affected by the choice of the large exponent: The cost is in the order of magnitude of traditional RSA decoding (without the use of the Chinese Remainder Theorem). It is noted, that when the re-encoding method is used, the signer must later handover the key cek and the random value s. Both values can be extracted from ecek within the RSA-PKCS#1 v2.1 structure. Namely, the value cek is directly returned by the decryption algorithm; retrieving in addition the random value s is possible but requires modifications to the program code of the decryption procedure. Decoding In this variant, the private key is handed over to the third party (e.g. judge). Thus, in the case of, e.g., RSA, it is easier to verify that the RSA function is one-to-one. For RSA, upon the reception of sk and pk, the recipient can easily calculate the factorisation p,q, and verify that they are prime, and verify that e is relatively prime to ((N)=(p-1)(q-1). The advantage of this method is that the choice of the exponent is not limited. In return, sk and the factorisation must be relinquished, when the encryption is verified. Consequently, if the verifier keeps a copy of the key or factorisation of the modulo, he can read all of the other messages encrypted with this public key. It must be further noted, that sk must be obtainable, that is, it must not be contained on a data medium that prevents the retrieval of the value (e.g. a signature card). As in the case of re-encoding, a trusted third party can be used to obtain a certified RSA key pair. The encrypted document is decrypted with the private key. Afterwards, it must be verified that the private key corresponds to the certified public key. This can be done in a simple manner (such as through the verification of the RSA exponent equation ed=1 mod ((N)). 5. Realisation In order to realise the described concepts in software, additional software components (for each encryption method) must be developed for the verification of the uniqueness of the encryption and decryption. Furthermore, these new components must be trustworthy. If encrypted data is signed using qualified time-stamps or signatures in accordance to the German Signature Law, then the verification components require a declaration from the software producer. Furthermore, if accredited signatures are to be verified, then security-certified components are necessary. To illustrate the deployment of the re-encoding method, based on the above-mentioned example solutions (CMS with asymmetric RSA encryption and one of the given symmetric algorithms), one could imagine the following procedures and software component functionality: The demonstrator establishes D and cek, for which standard encryption software can be utilised. For the re-encoding, he must give the verifier (e.g. judge) the stored document (CMS enveloped data), as well as s, cek and D. The certified software of the verifier must then re-encode ecek (using RSAenc (pk, s, cek)) and verify that it matches the ecek stored within the Recipient-Info of the CMS message. The certificate containing pk must be then retrieved from the CMS message and it must be verified that it is consistent and was issued by an accredited CA. If all these tests pass, then the software can decrypt the content using cek and compare it with D (received from the demonstrator). If they match, then the decrypted document D corresponds to the stored sD and any (verified and valid) time-stamps or signatures for sD are valid for D as well. In the case that decoding is used, the following steps are imaginable: The verifier receives the stored document fD and the private key. The verifier now decodes the stored ecek with his trustworthy software, that is, he calculates RSAdec (sk, ecek) = cek. After this, the software conducts the verification of the key and related certificate, as already described for re-encoding (e.g. that pk and sk correspond to one another). Finally, the stored, encrypted content is decrypted. Then it can be determined whether the derived D corresponds to the stored sD and that any (verified and valid) time-stamps or signatures for sD are valid for D as well. As part of the verification of the keys properties, it is suggested to check whether the certificate (containing the key) was issued by a trusted, accredited CA. In the context of signatures, in practise, currently known CAs may be considered trustworthy. Admittedly, unlike for signature keys, there are currently no legal guidelines for the certification of encryption keys. Thus, it is unclear whether the assurance of an encryption key's properties will be legally accepted solely based on virtue of a certificate. (That is, that the key was created and adheres to the aforementioned requirements on such keys.) If one wishes to eliminate this legal uncertainty, one can use an RSA signing key that was generated and certified by a qualified CA according to SigG. This signing key is then used in adherence to the security aspects of RSA encryption, instead of RSA signing. 6. Conclusion and Outlook The signing or time-stamping of encrypted documents is not without its problems, since encryption algorithms do not necessarily guarantee uniqueness. Unfortunately, the corresponding risk is not reliably quantifiable for current encryption methods. This risk is avoidable through additional constraints on the quality of the key and its verification, as well as through parallel signing of the method description and parameters. Solutions are possible based on the current Cryptographic Message Standards, using algorithms, such as RSA and DES. The solutions have differing advantages and disadvantages. The decoding variant has the advantage that the recipient need not know any other parameter besides his private key, which is always needed to decrypt the document. The disadvantage is that the private key must be disclosed when the uniqueness of the document is to be proven. This appears to be bearable, so long as this disclosure only occurs in the rare case of a court case and the key is only given to a judge or expert. The re-encoding variant avoids this disadvantage. We find that the solution with large RSA exponents is particularly suitable, since it requires neither a certificate nor the disclosure of the private key. Its disadvantage is however, that the random value s must be handed over; hence it must be separately stored. Other solutions, besides the named ones, are possible, if the possibility of decryption is foregone. This is reasonable when documents are only to be stored to prove their timely existence and the user saves a copy himself. Then Commitment-Techniques [Gold_2001] could be utilised, instead of encryption methods. It must be noted that when traditional encryption algorithms are used, their security reduces over time. Fortunately, the importance of the confidentiality of a document also, in general, reduces over time. Thus, the risk that the encryption is broken in the long-term is often acceptable. Literature [AKS_2002] Agrawal, M./ Kayal, N./ Saxena, N. (2002): PRIMES is in P, http://www.cse.iitk.ac.in/news/primality.html [BPRS_2002] Brandner, R./ Pordesch, U. Ronagel, A./ Schachermayer, J. (2002): Langzeitsicherung qualifizierter elektronischer Signaturen, DuD 2/2002, 97 - 103. [BRPO_2003] Brandner, R./ Pordesch, U. (2003): Konzept zur signaturgesetzkonformen Erneuerung qualifizierter Signaturen, DuD 6/2003, 354 - 359. [CMR_1998] Canetti, R./ Micciancio, D./ Reingold, O. (1998): Perfectly One-Way Probabilistic Hash Functions, STOC98. [Fisch_1999] Fischlin, M.: Pseudorandom Function Tribe Ensembles Based on One-Way Permutations, Eurocrypt99. [Gold_2001] Goldreich, O.: The Foundations of Cryptography Volume 1, Cambridge University Press. [H_1999] Halevi, S.: Efficient Commitment Schemes with Bounded Sender and Unbounded Receiver, Journal of Cryptology, vol. 12(2), 1999 [Pord_2003] Pordesch, U.: Die elektronische Form und das Prsentationsproblem, Baden-Baden 2003.  This paper firstly was published in german language: Nichtabstreitbarkeit trotz Verschlsselung, Datenschutz und Datensicherung 3 / 2004, pp 163-168. Basic ideas were developed in the project ArchiSig - Conclusive and secure long term archiving of digitally signed documents.supported by the German Federal Ministry of Economics and Technology (VERNET program) under the number 01MS121.  A value is called valid, when it is a possible value, according to the algorithms specification, that is, an allowed key or a correct cipher text.  Admittedly, hash methods, such as SHA-1, have also only a finite domain, because the length of input is bounded. However, in theory, hash methods possess an unbounded domain.  For example, one can choose p-1 and q-1 as the product of small primes 2,3,5,7, and e as the product of a large subset of these primes.  Normally encryption keys should not be used as signature keys and vice versa. Also key usage field of key certificate may restrict usage of key to signing. On the other hand no one can hinder others to use RSA public signature verification key as public encryption key. Anmerkungen  STYLEREF "berschrift 1"Erreur! Style non dfini. Fischlin / Pordesch, Non-repuduation despite Encryption "#23]^_tu'()IJLkl01   ' ( 7 8 89ijuv  źԱ 5mH sH jUmH sH jUmH sH 0J;jU jUNH NHmH sH  0J;mH sH jUmH sH jUmH sH j0J"UmH sH mH sH >$KL^ 5 L??CEƀy. & Fx$a$D~:[#$?b#rs,CDMSfgO P =!>! """""M#N#b#$r$$$ &"&&&N' ^JmH sH j0J"6U6NHmH sH  6mH sH NH]mH sH  ]mH sH 6]mH sH  5mH sH mH sH  NHmH sH I?O(>! "b#r$j%&N'*+K+,..//%. & F?N'$(%((( ) )))|*}*+K+++H,I,,--$.%......[/\///`0a000/10122l3m3u3K44445>555{6|66666666 7#7%7&7(7)7/78886CJH*aJmH sH  j6 jj66]mH sH  ]mH sH NHNH^JmH sH  ^JmH sH  6mH sH  j0J"U NHmH sH mH sH D/01#3u3K469<=>>AA$CCDDHF\F{FGCEƀyF`888899m9n999999::=;>;<<a=b=y=z==>>>??@@iAjA~AAAABB$CCCC[D\DDDDEEFGEGRGSG[G^GH I III#J-J.JJKKbKcKKK;MVM 5mH sH 6NHmH sH NH ]mH sH  6mH sH  jj66]mH sH  NHmH sH  j0J"UmH sH H*aJmH sH IG^GHkJJ LNNPyRRSS%T n7d5$7$8$9DH$]7a$VMMMNNNNOOOOPPPPPPQ Q Q-Q8Q=QyQzQ{QQQQQQQR>RQRVR^R_RjRkRvRxRyRRSSSSSSTTTU ULUMUkUkVlVVVWWWWWWW6CJH*aJmH sH  j6 6mH sH B*mH phsH NH ^JmH sH 6]mH sH NHOJQJmH sH OJQJmH sH  NHmH sH mH sH DW$W.WXX?Y@YvZwZ]]}^~^__O_P_]_e_``&a'a.a7aEbJbzb{bbbbbccgdhdeeeeeeefffffffgggg3h4hkk=n>nnn:p;pppqqrrrratbtuuxxj0J"UmH sH  jj66]mH sH B*mH phsH  NHmH sH mH sH  ]mH sH  6mH sH NdffKhl5orrx:y]zhzz{|||]}}D~d!CEƀyxxyy:yyy zRzSzhzzY{Z{|2|3|||}}},~-~D~E~~de ڂۂ0\5\mHnHsH  mHnHsH  jUB*mH phsH  j0J"U NHmH sH NHmH sH /d0123456789:;<=>?@ABC$a$!CDEFGHIJKLMNOPQRSTUVWXYZ[\5 0 00&P . A!n"n#$%7 DyK mfischlin@cs.ucsd.eduyK :mailto:mfischlin@cs.ucsd.eduDyK !ulrich.pordesch@zv.fraunhofer.deyK Pmailto:ulrich.pordesch@zv.fraunhofer.deDyK brianhunter@canada.comyK <mailto:brianhunter@canada.comE i\@\ Normal&$d$5$7$8$9DH$`a$CJKH_HmHsHtHp@p Titre 1'$$$d*$5$7$8$9D@&H$'5@CJ4KHOJQJ_HmHsHtH@" Titre 2,H27$$ 9 @Bdx*$5$7$8$9D@&H$#5CJKHOJQJ_HmHsHtH6@!"6 Titre 3,H3 d@&CJ01"0 Titre 4,H4 0@&:A": Titre 5 <@& CJOJQJF"F Titre 6<@&`6CJOJQJ:": Titre 7 & F T(@&B"B Titre 8<@&` 6OJQJB "B Titre 9 <@&` 6OJQJ2A@2 Police par dfautdd berschrift 1 Untertitel$dh@& 5B*CJ$ph`` Autor#$$, 5$7$8$9DH$a$ CJKHOJQJ_HmHsHtHXO"X Appetizerd5$7$8$9DH$6KH_HmHsHtHHOH Standard (ohne Einzug) `*2*  Commentaire>'@A> Marque de commentaireCJBRB Balken#%d0O0^`D+bD  Note de finsd8^`sCJ<*@q< Appel de note de finH*d @d Pied de page '5$7$8$9DH$OJQJ_HmHnHsHtHu22 HalbezeiledCJ 8@8En-tte$99]9^9a$4!4 Legende $a$OJQJ6a6 LiteraturT^T` Quadratv & F>TnTf^`|| Raute_>TTf,)@, Numro de pageVV Tabelle ((5$7$8$9DH$CJOJQJ_HmHsHtHD@D Note de bas de page!dCJR&@!R Appel note de bas de p.CJH*OJQJkHD!2D Standard (nach Balken)#(,B, Quadrat2 $^BORB Standard (vor Balken)%($b$ Autor2&V!rV Gesetzberschrift' 7@x^`5D!D Inhalt-Autor($da$ CJOJQJ|| Inhalt-Rubrik+)  B-D5$7$8$9DH$M #CJ OJQJ_HmHnHsHtHuPP Inhalt-Titel*$  ZBd(*$5CJ88Kopfzeile-Rubrik+CJ$ Qradratbersicht,$x$d%d&d'd-D>TnM NOPQTfa$ Quadrat_SW_->TnTfO!" berschrift 2 (ohne Nummer).$ & F>T.@& Tf^`a$(O( AutorZitat60O0 Quell-Code OJQJkHF>F Titre1$d`a$5CJ0KHOJQJ1" berschrift 3 (ohne Nummer)y2 & F>T.@& Tf^`(!B( Bild3$da$("!( Lgende4$a$~R~ Spiegelstrich-Absatz 1$5$ & Fw 75$7$8$9DH$CJOJQJ_HmHsHtHfqbf Beispielberschrift*6 & FP hP^`5VV Beispieltext(7d5$7$8$9DH$^`KH Aufzhlung_numeriert98$ & Fdx5$7$8$9DH$^`a$ CJKHaJ:12: Kommentarthema9 5CJ\HH Sprechblasentext:CJOJQJ^JaJ:U@: Lien hypertexte >*B*phff Aufzhlung 14<$$ & F d<5$7$8$9DH$a$CJKHDD Aufzhlung 2= 7^7`VV Aufzhlung nummeriert> & F^`HOH Spiegelstrich-Absatz 2 ? & Ftt Spiegelstrich-Punkt4@ hhdx5$7$8$9DH$^h`CJKHZZ Zeichen kursiv$Adx5$7$8$9DH$`6CJRO!R Zeichen kursiv Char6CJKH_HmHsHtH2 Wichtig{C & F7d$d%%d%&d%'d%5$7$8$9DH$N%O%P%Q%]7`CJKHOJQJaJ`YB` Explorateur de documentD-D M OJQJ^J" $3m\~ \lo  \~             #     \~$KL^5  L ?O(> br j!p""%&K&'))**0,#.u.K/147899<<$>>??HA\A{AB^BCkEE GIIKyMMNN%O ?0> ?0> ?00(0000000(0000000000000000000000@!0@!0@!0@!0@!0 0@0@0@0@0@0@0@0@0@0 0 GN'8VMWx\CFHJLMO?/GddC\DGIKNPQ[E2^t(Ik\~XXX)D   a[b$kjxH86nuJ[C2$r2=oVDb$(g!^s}H2$WcN =vL2$XՎ"֟C;Jt:: 2$F' ,ƏY2$p aA1xH2$P2p_&\>EuL 2$YX_~*,.g2$cU#b@H 0(  Z0 0(  B S  ?\~ _Ref32998955 _Ref33003897 _Ref50787302]~ww]~)1JLPQXk   QS:<  NRhk<?ae03KNrv,/v|5;=C Z` ! " q !!E"H"L"O"p"v"x"{"""""%%%%&&&!&6&<&>&A&&&&&''|(()))H)K)))))5*8***************$+(+P+T+k+n+++++++,,,,,,,,,,,-/-------------.!.B.E.{.}......... /#/-/1/4/;/=/?/D/G////////00000N0P0'2)2w2222"3+333445555'6-6J6P6U6\677f7o788,83889999999,:7:;< < <"<$<<<<<<<<<<<7=:=h=l==================>> >>>>>>!>$>b>d>x>z>>???@S@U@|@~@@@A A(A.A?AEAIAKATAVA]AaAdAjAnApAuAxAAAAB'B)BoBuBxB~BBC&C)C/C2C5C;C>C@CCCGCSCUC^C`CgCjCCCCCCCCCCCCCCCCCqDwD#EjEkEzE|EEIFNFFFFFIIII_KbKKKKKL,L8LMQMVMvMyMM#N&NO^P_PjPRRGTJTzT}TTTUUXXZZ7[;[t[w[.\6\]] ]]E]H]]^ _ _aavdyd'e*emeqeyeeeeeeeeffffOgQggghhVhZhhhhhhhhh1i3i8i:iiijjkksss9t u\u]ugusuzuuuuuvvvww%w,w6w=wEwxxfxlxDyFyJyKyPyQyXy]yfyjypyqyyyyyRzfz}}}}}}}}}} ~/~0~1~9~:~Z~]~LPMZ  Z :<p"v"i##&&K&M&5)?)**,,p-|-99 < <<<==IAKA]AaA5C@CgCjCFFRRRRSSWW[[F]H]]^ _ _eeOgQghhiijjmmDyKyPy\zfz^|g|}}}}}}}}}0~9~:~]~33333333333333333333333333333333333333333$KkkEE_PjPmms9t]uhuDy{|}}}}}}}}}}/~9~:~]~Peter SylvesterC:\WINNT\Profiles\Administrateur\Donnes d'applications\Microsoft\Word\Enregistrement automatique deFischlinPordesch_NonrepudiationDespiteEncryption.asdPeter SylvesterIF:\chandon\europepki\FischlinPordesch_NonrepudiationDespiteEncryption.doc82v=vyxP$;4^z\<sH.iX R-#\<d.iX zqY%Ab {O*^w Z2C] \<6  \<) |sM .iX X r "&S~ ȷrHA_ ^L%p2.iX d`hghT<D 3\<w>*$6^4bd^au\<;6\<fxh<8 `hsRhjp?X ^$%]^^3:,cFY:\< l^v\<VcO|.iX  .iX !^m"^4r"^`",@^E>^x>\~)?>`hx@m6?AeC^C,yKjD^ EePZ.iX GZ { \ho"\ꂏ]j^^iH_^,|`.9`^G};`zk`9`\<e&b^jg0cdL6 c:&d\</i^rifTI2j>뼾;"k.iX joH[Uo^gq.iX >q8jtfr\<cr6E5xr^TNr`h;LNs /:s55UBt`hC*tu^1%+v^zvHNXw`h+w^$|wZ24w^S?x^w)y uvy^:"z {XIz\<@'|P|^''}^1n\< hh^h`OJQJo(@@.@..@...@ ....@ .....@ ......@ .......@ ........*hh^h`CJ-@^`@^`@^`@@^`@ hh^h`OJQJo( K^`OJQJo( ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(@^`@^`??@^`@^`@^`h^`o(- ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(@hh^h`.h8^`h..^`...x ^`x.... @ ^` .....  X^ `X ......  ^ `....... 8^`8........ `^``.........@^`()@^`P^`P@@^@`.0^`0..``^``... ^` .... ^` ..... ^` ...... `^``....... 00^0`........@@^`hhh^h`CJOJ^Jo( h T^T`OJQJo(h pp^p`OJ QJ o(h @ @ ^@ `OJQJo(h ^`OJQJo(oh ^`OJ QJ o(h ^`OJQJo(h ^`OJQJo(oh PP^P`OJ QJ o(@^` hh^h`OJQJo(@^`@^`@^` hh^h`OJ QJ o(@^`h^`. ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo(" @^`Vh^`Vo(- ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(@^`@^`hh^h`o(.@^`()@^`@^`@^`T^`To(A ^`.S LS ^S `L.# # ^# `.^`.L^`L.^`.cc^c`.3L3^3`L.@@@^`@^`@^`h^`CJ-h ^`OJQJo(oh pp^p`OJ QJ o(h @ @ ^@ `OJQJo(h ^`OJQJo(oh ^`OJ QJ o(h ^`OJQJo(h ^`OJQJo(oh PP^P`OJ QJ o(hh^h`o(-@^`h^`^`.^`..8^`... ^` .... ^` ..... ^` ...... ^`....... ^`........@@^`@^`@^`@^`@^`hh^h`)hh^h`CJ-hh^h`CJ-@^`^`o([]^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.@^`8^`56()^`o(Teil :h^`o(.^`o(.8^`o(..^`o() ^`o( ..... ^`o( ...... ^`o(....... ^`o(........@@^`@^`??h^`.^`.8^`..8^`... ^` .... ^` ..... ^` ...... ^`....... ^`........hh^h`)@^`hh^h`o(-@^`hh^h`)@^`@^`??@^`@^`^`o([]^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.@^`@^`hh^h`.h8^`h..8^`...@^`@.... @ ^` .....  X^ `X ......  ^ `....... 8^`8........ `^``.........@^`^`o(- ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(@^` ^`o(hH) ``^``o(hH) ^`o(hH) 00^0`o(hH() ^`o(hH() ^`o(hH() h^`o(hH[] ^`o(hH. 88^8`o(hH.@^`h^`.h^`.hpLp^p`L.h@ @ ^@ `.h^`.hL^`L.h^`.h^`.hPLP^P`L.@{h{^{`hOJPJQJ^Jo(- ^`OJQJo(o ^`OJ QJ o(   ^ `OJQJo(   ^ `OJQJo(o [[^[`OJ QJ o( ++^+`OJQJo( ^`OJQJo(o ^`OJ QJ o(@@^`@^`@^`@^`@^`@@^`@^`h :^`:OJQJo(h ^`OJQJo(oh pp^p`OJ QJ o(h @ @ ^@ `OJQJo(h ^`OJQJo(oh ^`OJ QJ o(h ^`OJQJo(h ^`OJQJo(oh PP^P`OJ QJ o(Th^T`o(- ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(hh^h`()@^`@^`hh^h`o(.hh^h`o(-@h^`.^`.^`..^`) ^` .... ^` ..... ^` ...... ^`....... ^`........@@K^`CJo(- ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(hh^h`CJ- hh^h`o(hH) ^`o(hH) 88^8`o(hH) ^`o(hH() ^`o(hH() pp^p`o(hH()   ^ `o(hH[] @ @ ^@ `o(hH.   ^ `o(hH.@^`@^`@^`@^`hh^h`o(- hh^h`OJQJo(@^`@^`hh^h`o(-h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJ QJ o(hH@^`@^`hh^h`CJ- hh^h`OJ QJ o(@hh^h`CJ-@^`@ hh^h`OJQJo(@^`h^`CJo(- ^`OJQJo(o pp^p`OJ QJ o( @ @ ^@ `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( ^`OJQJo(o PP^P`OJ QJ o(@^`@^`\^`\o(.^`.L^`L.  ^ `.  ^ `.[L[^[`L.++^+`.^`.L^`L.P^`Po(@@^@`o(0^`0o(..``^``o(... ^`o( .... ^`o( ..... ^`o( ...... `^``o(....... 00^0`o(........@^`@^`@^`hh^h`o(.@^`@^`@^`??@^`@^`hp^h`Fallbeispiel :@^` Th^T`OJQJo( ^`OJQJo(o S S ^S `OJ QJ o( # # ^# `OJQJo( ^`OJQJo(o ^`OJ QJ o( ^`OJQJo( cc^c`OJQJo(o 33^3`OJ QJ o(@^`h^`o(A ^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.@^`@^`@^`@Qspu,|`uvp;$Ee)5UBtdPu)?>uTNrHNXw z 9Jf<1n&d9e<'(D 3vC] )0au6MedLXIz9`jtfr:R-#(uusuHuuriuyxw Ml)MEh37zqhuL|Ujg0cG};`#/X u3:qzv <0H+uJ# N2x> 7Tu@uk7;vYvYuu7,%]fD9TI2jw)y14uk`Tu(29joW; \W;uAPLd5>ZmIgq .|SNGZ`"* &%Ab:"zH3M7X @'|e&bUo1%+v64N&A_ VcO )0a,#4r"fx EC"\E>}U"0ghiH_x@1N) sRh.9` cP| uvym"4w6|u @^`CJo(phOJQJnu`@^`CJo(phOJQJ\u @^`B*CJOJ QJ o(nȾu @^`B*CJOJQJo(4u l@^`CJOJQJo(?u c@^`u @ ^`OJQJo(-Tu @hh^h`.u @h h^h`OJQJo(_u e@ R^R`OJQJo(?tu @ ^`OJQJo(u @^`-,u c@^`CJOJQJo(u @  ^`OJQJo(u @CJ$OJQJo(Lu @CJ$OJQJo(-iu @  ^`OJQJo(u Xq@ OJQJo(-`u @ R^R`OJQJo(--_NIƄ$V6Do}LWJ:[#=(RL(   }}}}}]~@GGqEGG("#\~p@p&pP@Unknown Carl Wallace GTimes New Roman5Symbol3& Arial71Courier;" HelveticaE2LettrGoth12 BT3Times5& z!Tahoma?5 Courier New;Wingdings" "FR&ۄF'c3\h5!xx0dz{wI 3QH'D:\Brandner\Publikationen\DuD\Paper.dot"Non-repudiation despite EncryptionMarc Fischlin / Ulrich PordeschPeter SylvesterOh+'0 , DP l x  #Non-repudiation despite Encryptionson- Marc Fischlin / Ulrich Pordescharcarc Paper.dotliPeter Sylvester6teMicrosoft Word 9.0i@r@%nV,@r)1@?r6c՜.+,D՜.+,t0x  iiD3z #Non-repudiation despite Encryption TitreHck _PID_HLINKS_AdHocReviewCycleID_EmailSubject _AuthorEmail_AuthorEmailDisplayName_PreviousAdHocReviewCycleIDAhx\mailto:brianhunter@canada.comXs(mailto:ulrich.pordesch@zv.fraunhofer.de!]mailto:mfischlin@cs.ucsd.edu Background paperiew"Ulrich.Pordesch@sit.fraunhofer.deyUlrich PordeschKN  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRTUVWXYZ\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F`Žr6Data S1Table[KWordDocument7SummaryInformation(DocumentSummaryInformation8CompObjjObjectPool`Žr6`Žr6  FDocument Microsoft Word MSWordDocWord.Document.89q