WO2003063410A1 - Cryptosystem - Google Patents

Cryptosystem Download PDF

Info

Publication number
WO2003063410A1
WO2003063410A1 PCT/GB2003/000202 GB0300202W WO03063410A1 WO 2003063410 A1 WO2003063410 A1 WO 2003063410A1 GB 0300202 W GB0300202 W GB 0300202W WO 03063410 A1 WO03063410 A1 WO 03063410A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
trusted
message
party
private key
Prior art date
Application number
PCT/GB2003/000202
Other languages
French (fr)
Inventor
Hyun Ku Dr Yeun
Original Assignee
Hogg, Jeffery, Keith
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hogg, Jeffery, Keith filed Critical Hogg, Jeffery, Keith
Publication of WO2003063410A1 publication Critical patent/WO2003063410A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/3013Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the discrete logarithm problem, e.g. ElGamal or Diffie-Hellman systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Definitions

  • This invention relates to cryptosystems and methods for encrypting/decrypting and signing messages.
  • Diffie and Hellman introduced the public key exchange that is based on the Diffie Hellman Problem (DHP) that is closely related to the well known Discrete Logarithm Problem (DLP).
  • DHP Diffie Hellman Problem
  • DLP Discrete Logarithm Problem
  • the intractability of DLP is equivalent to the security of the ElGamal public key scheme.
  • the RSA public key cryptosystem was introduced in 1978, and may be used for both secrecy and digital signatures.
  • the RSA cryptosystem works in Z n , where n is the product of two large primes p and q, and its security is based on the difficulty of factoring n, that is, the integer factorization problem. Since then, various ElGamal and RSA type cryptosystems have been proposed to enhance existing defences against "chosen ciphertext attacks".
  • Shamir proposed identity-based cryptosystems and signature schemes that enable simple key management in email systems. For example, when Alice sends an email to Bob at bob@cipherdoctor.com, she simply encrypts her message using the public key string bob@cipherdoctor.com. There is no need for Alice to obtain Bob's public key certificate.
  • TTP Trusted Third Party
  • Bob authenticates himself to the TTP and obtains his private key from the TTP.
  • Bob can then read his email.
  • PKI Public Key Infrastructure
  • An object of the invention is to provide an improved cryptosystem which has equivalent functionality to ID based public key cryptosystems, but which avoids the need for key escrow/PKI.
  • the invention consists in a cryptosystem in which users send and receive messages with the help of a trusted third party for security purposes making use of private keys and public parameters which encapsulate said private keys, each user holding a private key and the trusted third party being entrusted with a corresponding private key for each user, and the trusted third party being adapted so that it is responsive to a challenge from a user by issuing a response which encapsulates the corresponding private key so that the user can use the response in combination with the private key already held by the user to decrypt or sign a message.
  • the transmitting user encrypts the message to a recipient user using the public parameters which encapsulate the private keys of the recipient user.
  • One of these private keys is held by the recipient user, but the other is held by the trusted third party, and thus the recipient user issues a challenge to the trusted third party so as to obtain a response in which the other private key is encapsulated.
  • the private key held by the trusted third party is therefore kept secret, but it can be accessed by the recipient in its encapsulated form and used to decrypt the message.
  • the encryption process also makes use of private parameters generated by the transmitting user, and these are transmitted to the recipient user for use in the challenge and response so that the decryption process is suitably enabled.
  • These private parameters as well as increasing encryption security, also serve to encapsulate the private key in the response.
  • the transmitting user When the cryptosystem operates to sign a message, the transmitting user creates a multi-part signature which is transmitted with the message so that a recipient user can check the signature against the signed message.
  • the signature comprises one part generated directly by the transmitting user so as to encapsulate the private key held by the transmitting user, and another part encapsulating the response from the trusted third party following a challenge by the transmitting user, so that it incorporates the private key of the transmitting user held in trust by the trusted third party.
  • the signature also includes a private parameter generated by the transmitting user which is used in generating the other two parts of the signature and which is transmitted with said other two parts to the recipient user for checking the signed message. This serves to increase signature security.
  • the challenge preferably makes use of the ID of the user issuing the challenge, and this ID is also incorporated in the encryption process or signing process.
  • this ID is also incorporated in the encryption process or signing process.
  • the encryption and signing processes involve private keys, the challenge does not use a private key and thus the private keys held by users are kept secret from the trusted third party.
  • the invention is further defined in the appended claims and consists in user terminal means for a cryptosystem and trusted third party means for a cryptosystem, as well as the combination of these means in a cryptosystem and a method of enabling users to send and receive encrypted messages and to sign messages using a trusted third party.
  • the user terminal means and trusted third party means may comprise hardware and/or software.
  • Figure 1 is a schematic drawing showing encryption and decryption of a message, and
  • Figure 2 is a schematic drawing showing signing a message.
  • a trusted third party or key center TTP is established and publishes the public system parameters required by users of the cryptosystem to encrypt and sign messages.
  • the cryptosystem is based on the Diffie-Hellman scheme over multiplicative group Zp, which is cyclic.
  • the public system parameters consist of:
  • each user has two private keys %, one being held by and being secret to the user, and the other being held by and being secret to the TTP.
  • a typical user Alice has a private key XA X
  • the TTP holds a corresponding private XA 2 , where (1 ⁇ %A A 2 ⁇ q)
  • a typical user Bob has a private key g, , and the TTP holds a corresponding private key X A ⁇ , where (1 ⁇ XB XB 2 ⁇ q).
  • the trusted third party TTP comprises a computer TTPM set up as a server with server software so as to be accessible over a network, such as the Internet, to users A, B, I.
  • the server holds the public parameters and makes them available to users A, B, and holds the user keys XA 2 , XB 2 private in a secure memory for use as described below.
  • Each user A, B accesses the server TTPM via a user terminal TA, TB which comprises a computer such as a laptop or hand held device.
  • Each user terminal has user software installed, which may be downloaded from the server TTPM when the user A first registers with the cryptosystem.
  • Registration involves the user software running an algorithm that generates each of the private keys X X , XA 2 from an input variable selected by the user.
  • One private key X AX is held in a secure memory in the user terminal TA and the other private key X A2 is sent to the server TTPM, which holds it in its secure memory.
  • Registration of user A is then complete and they can use the cryptosystem to send messages to and receive messages from other registered users such as B.
  • a user A such as Alice who wants to send a message to user B, such as Bob, randomly chooses two integers ki and k 2 , where 1 ⁇ k ⁇ , k 2 ⁇ q, and computes the following:
  • ID B is the binary string for the email address of Bob, for example, bob@cipherdoctor.com or a more complex form of identification for additional security.
  • the encrypted message e is then generated as follows:
  • Alice sends the encrypted message e and the parameters ri and r 2 to Bob.
  • CHA (ri, r 2 , ED B ) and sends this as a challenge to TTP.
  • this decryption formulation for m is the inverse function of the encryption formulation of e quoted above, and thus decryption is effective.
  • Alice randomly chooses two integers ki and k 2 , where 1 ⁇ k ⁇ , k 2 ⁇ q, and computes the following:
  • JD A is the binary string for the email address of Alice.
  • CHA (r, m, IDA) and sends this as a challenge to TTP.
  • the recipient can be certain as to the true identity of the signatory.
  • TTP trusted third party
  • the pairs of public parameters P PA 2 and B B 2 involve system parameters gi and g 2 , which take different values
  • gi and g 2 could be set at the same value to simplify the system.
  • the values of two or more of the system parameters gi, g 2 , ... g vide could be the same.
  • the security of the proposed scheme is based on the security of Diffie-Hellman problem and one-way collision resistance hash-functions. Given the fact that there is no known method for "breaking" DHP or for finding collisions on one-way colUsion-resistance hash-functions, it is computationally infeasible to break the proposed scheme.
  • the use of two or more private keys per user, one held by the user and one by each TTP, and the challenge and response technique with each TTP enables a computationally secure cryptosystem to be set up without embedding key escrow and without any PKI requirement so all users enjoy secure communication with each other without possessing verified certificates.
  • the invention therefore provides an implicitly authenticated public key cryptosystem which avoids disclosing user's private keys even to the TTP.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Users (A, B) send and receive messages in a cryptosystem with the help of a trusted third party (TTP) making use of private keys (X) and public parameters (P) which encapsulate said private keys (X), each user (A, B) and the trusted third party (TTP) being entrusted with a private key (XA1, XB1), (xA2, XB2). The trusted third party (TTP) is adapted so that it is responsive to a challenge (CHA) from a user (A, B) by issuing a response (RES) which encapsulates the corresponding private key (XA2, XB2) so that the user can use the response (RES) in combination with the private key (XA1, XB1) already held by the user to decrypt or sign a message. Preferably, the encryption process and the challenge make use of public parameters (P) and private parameters (r1, r2) generated by the transmitting user. A signature Sig(M) comprises one part (S1) generated by the transmitting user to encapsulate the private key (XA1) held by the transmitting user, and another part (S2) encapsulating the response (RES) from the trusted third party (TTP).

Description

CRYPTOSYSTEM
Field of the Invention
This invention relates to cryptosystems and methods for encrypting/decrypting and signing messages.
Background of the Invention
In 1976 Diffie and Hellman introduced the public key exchange that is based on the Diffie Hellman Problem (DHP) that is closely related to the well known Discrete Logarithm Problem (DLP). The intractability of DLP is equivalent to the security of the ElGamal public key scheme. The RSA public key cryptosystem was introduced in 1978, and may be used for both secrecy and digital signatures. The RSA cryptosystem works in Zn, where n is the product of two large primes p and q, and its security is based on the difficulty of factoring n, that is, the integer factorization problem. Since then, various ElGamal and RSA type cryptosystems have been proposed to enhance existing defences against "chosen ciphertext attacks".
In 1984 Shamir proposed identity-based cryptosystems and signature schemes that enable simple key management in email systems. For example, when Alice sends an email to Bob at bob@cipherdoctor.com, she simply encrypts her message using the public key string bob@cipherdoctor.com. There is no need for Alice to obtain Bob's public key certificate. When Bob receives the encrypted email he contacts a Trusted Third Party (TTP). Bob authenticates himself to the TTP and obtains his private key from the TTP. Bob can then read his email. This system does not require a Public Key Infrastructure (PKI) so Alice can send encrypted email to Bob even if Bob has not set up his public key certificate. However, this system employs key escrow since the TTP knows Bob's private key.
Summary of the Invention
An object of the invention is to provide an improved cryptosystem which has equivalent functionality to ID based public key cryptosystems, but which avoids the need for key escrow/PKI. The invention consists in a cryptosystem in which users send and receive messages with the help of a trusted third party for security purposes making use of private keys and public parameters which encapsulate said private keys, each user holding a private key and the trusted third party being entrusted with a corresponding private key for each user, and the trusted third party being adapted so that it is responsive to a challenge from a user by issuing a response which encapsulates the corresponding private key so that the user can use the response in combination with the private key already held by the user to decrypt or sign a message.
When the cryptosystem operates to encrypt/decrypt a message, the transmitting user encrypts the message to a recipient user using the public parameters which encapsulate the private keys of the recipient user. One of these private keys is held by the recipient user, but the other is held by the trusted third party, and thus the recipient user issues a challenge to the trusted third party so as to obtain a response in which the other private key is encapsulated. The private key held by the trusted third party is therefore kept secret, but it can be accessed by the recipient in its encapsulated form and used to decrypt the message.
Preferably, the encryption process also makes use of private parameters generated by the transmitting user, and these are transmitted to the recipient user for use in the challenge and response so that the decryption process is suitably enabled. These private parameters, as well as increasing encryption security, also serve to encapsulate the private key in the response.
When the cryptosystem operates to sign a message, the transmitting user creates a multi-part signature which is transmitted with the message so that a recipient user can check the signature against the signed message. The signature comprises one part generated directly by the transmitting user so as to encapsulate the private key held by the transmitting user, and another part encapsulating the response from the trusted third party following a challenge by the transmitting user, so that it incorporates the private key of the transmitting user held in trust by the trusted third party. Preferably, the signature also includes a private parameter generated by the transmitting user which is used in generating the other two parts of the signature and which is transmitted with said other two parts to the recipient user for checking the signed message. This serves to increase signature security.
The challenge preferably makes use of the ID of the user issuing the challenge, and this ID is also incorporated in the encryption process or signing process. However, it is a feature of the invention that, although the encryption and signing processes involve private keys, the challenge does not use a private key and thus the private keys held by users are kept secret from the trusted third party.
The invention is further defined in the appended claims and consists in user terminal means for a cryptosystem and trusted third party means for a cryptosystem, as well as the combination of these means in a cryptosystem and a method of enabling users to send and receive encrypted messages and to sign messages using a trusted third party. The user terminal means and trusted third party means may comprise hardware and/or software.
Brief Description of the Drawings
The invention will now be described by way of example with reference to the accompanying drawings in which:
Figure 1 is a schematic drawing showing encryption and decryption of a message, and;
Figure 2 is a schematic drawing showing signing a message.
Description of Embodiments of the Invention
A trusted third party or key center TTP is established and publishes the public system parameters required by users of the cryptosystem to encrypt and sign messages. The cryptosystem is based on the Diffie-Hellman scheme over multiplicative group Zp, which is cyclic. The public system parameters consist of:
p - a large prime, q - a large prime divisor of p - 1, g! and g2 - integers of order q where (1 <gι, g2 <q), h - a one-way collision-resistance hash-function.
Also, each user has two private keys %, one being held by and being secret to the user, and the other being held by and being secret to the TTP. For example, a typical user Alice has a private key XAX , and the TTP holds a corresponding private XA2, where (1 <%A A2 <q); and a typical user Bob has a private key g, , and the TTP holds a corresponding private key X, where (1 <XB XB2 <q).
Based on these private keys ^A A2, XB XB1 corresponding public parameters P are published as follows:
Figure imgf000006_0001
PA2 =g2 Λ2 moά p PBl =g B" mod p
Figure imgf000006_0002
Thus the public system parameters consist of p, q, h, gi, g2, P fh, where i = A, B, I.
In a typical implementation of the invention, the trusted third party TTP comprises a computer TTPM set up as a server with server software so as to be accessible over a network, such as the Internet, to users A, B, I. As illustrated in Figures 1 and 2, the server holds the public parameters and makes them available to users A, B, and holds the user keys XA2, XB2 private in a secure memory for use as described below. Each user A, B, accesses the server TTPM via a user terminal TA, TB which comprises a computer such as a laptop or hand held device. Each user terminal has user software installed, which may be downloaded from the server TTPM when the user A first registers with the cryptosystem. Registration involves the user software running an algorithm that generates each of the private keys X X , XA2 from an input variable selected by the user. One private key XAX is held in a secure memory in the user terminal TA and the other private key XA2 is sent to the server TTPM, which holds it in its secure memory. Registration of user A is then complete and they can use the cryptosystem to send messages to and receive messages from other registered users such as B.
In order to encrypt a message m e Zp, a user A, such as Alice who wants to send a message to user B, such as Bob, randomly chooses two integers ki and k2, where 1 <kι, k2 <q, and computes the following:
π = gl kl mod p, = g2 h mod p,
Figure imgf000007_0001
where IDB is the binary string for the email address of Bob, for example, bob@cipherdoctor.com or a more complex form of identification for additional security. The encrypted message e is then generated as follows:
Figure imgf000007_0002
Alice sends the encrypted message e and the parameters ri and r2 to Bob.
In order to decrypt the encrypted message e, Bob first computes CHA = (ri, r2, EDB) and sends this as a challenge to TTP. TTP then computes H = h(CHA) = h(rι, r2, IDB) and
HXJI2 , sends Bob a response RES = rι moa P.
Bob then uses the response RES together with his private key ._ to decrypt the message as follows:
m = e(rλ ' BχRES) l mod p.
It can be shown by simple substitution that this decryption formulation for m is the inverse function of the encryption formulation of e quoted above, and thus decryption is effective. In order to sign a message m e Zp, Alice randomly chooses two integers ki and k2, where 1 <kι, k2 <q, and computes the following:
Figure imgf000008_0001
H= h(r,m,IDA) and sι = kι — HXA mod q,
where JDA is the binary string for the email address of Alice.
Alice then computes CHA = (r, m, IDA) and sends this as a challenge to TTP.
-HX 2
TTP then computes H = h(CHA) and sends Alice a response RES = §2
Alice then computes
s2 = g RES mod q = g2 2 Λ mod q.
Alice then sends Bob a signature message Sig(m) = (r, Si, s2) which Bob can use to verify the message m by substitution in the formulation:
Figure imgf000008_0002
Thus if the signatory follows the above signature protocol, the recipient can be certain as to the true identity of the signatory.
In order to add message recovery to a digital signature scheme, a public redundancy function R and its inverse R"1 are introduced, the selection of R being critical to the security of the system.
To sign a message m e Zp, Alice randomly chooses two integers ki and k2, where 1 <kι, k2 <q, and computes the following: m = R(m), r = m' g"kχ g~ 2 k2 mod p, H= h(r,ID), and sι = k\ - HX mod q.
Alice then computes a challenge CHA = (r, ID) and sends it to TTP. TTP then computes
-HXA2
H = h(CHA) and sends the response RES = £2 to Alice. Alice then computes:
∑ = - g, -HX
S' 2 2RES mod q = g2 2 mod q
Alice then sends the signature message Sig(m) = (r, si, s2) to Bob. After receiving Sig(m), the message is verified by Bob using the formulation:
Figure imgf000009_0001
After checking the validity of m' the message is recovered by computing
m = R"l(m').
Whilst the invention has been described above with reference to a cryptosystem having just one trusted third party TTP, it will be appreciated that two or more TTPs may be provided, each being entrusted with a corresponding unique private key Xa„ for each user, so that a user is required to perform a challenge and response routine with each TTP before the user has all of the encapsulated private keys required for decrypting or signing a message.
Also, whilst the pairs of public parameters P PA2 and B B2 involve system parameters gi and g2, which take different values, gi and g2 could be set at the same value to simplify the system. Also, where there are two or more TTPs, the values of two or more of the system parameters gi, g2, ... g„ could be the same. The security of the proposed scheme is based on the security of Diffie-Hellman problem and one-way collision resistance hash-functions. Given the fact that there is no known method for "breaking" DHP or for finding collisions on one-way colUsion-resistance hash-functions, it is computationally infeasible to break the proposed scheme.
It will be appreciated that the use of two or more private keys per user, one held by the user and one by each TTP, and the challenge and response technique with each TTP, enables a computationally secure cryptosystem to be set up without embedding key escrow and without any PKI requirement so all users enjoy secure communication with each other without possessing verified certificates. The invention therefore provides an implicitly authenticated public key cryptosystem which avoids disclosing user's private keys even to the TTP.

Claims

1. User terminal means for a cryptosystem in which users (A, B) send and receive messages (m) with the help of a trusted third party (TTP) for security purposes making use of private keys (X) and public parameters (P) which encapsulate said private keys (X), each user (A, B) holding a private key (XA: , XB ) and the trusted third party (TTP) being entrusted with a corresponding private key (XA2, XB2) for each user (A, B), the user terminal means (TA, TB) being adapted to hold a user's private key (XA XBX) and to issue a challenge (CHA) to the trusted third party (TTP) and to receive a response (RES) from the trusted third party (TTP) which is responsive to said challenge (CHA) and which encapsulates the corresponding private key (XA2,XB2), the user terminal means (TA, TB) using the response (RES) in combination with the private key (X BI already held by the user (A, B) to decrypt a received encrypted message (e) or sign a message (m) to be transmitted.
2. User terminal means as claimed in claim 1 which, for a user (A) wishing to transit a message (m), is adapted to make user parameter selections (ki, k2) and to generate private parameters (r; ri, r2) which encapsulate said user parameter selections
Figure imgf000011_0001
k2), the user terminal means (TA) incorporating said user parameter selections (ki, k2) in the challenge (CHA), and the trusted third party (TTP) incorporating said user parameter selections (ki, k2) in the response (RES).
3. User terminal means as claimed in claim 2 which, for a transmitting user (A), encrypts a message (m) to a recipient user (B) using the public parameters (PB PB2) which encapsulate the private keys (XBX XB2) of that recipient user (B), and private parameters (t\, r2) generated for the transmitting user (A), the private parameters (n, r2) being transmitted to the recipient user (B) to decrypt the encrypted message (e).
4. User terminal means as claimed in claim 3 which, for a transmitting user (A) selects integer user parameter selections (ki, k2) and uses each in a public generator function to generate a respective one of the private parameters (ri, r2).
5. User terminal means as claimed in claim 4 in which the message (m) is encrypted according to the general formulation
mPβ ^PB^ dp,
where H is an exponent function that incorporates the private parameters (ri, r2) and p is a public system parameter in the form of a large prime integer.
6. User terminal means as claimed in claim 5 in which the public generator function for the private parameters (rls r2) takes the form
Figure imgf000012_0001
and r2 = g2 mod p, and in which PB2 =
Figure imgf000012_0002
mod p and PBX = gi Xβl mod p, where gi and g2 are public system parameters.
7. User terminal means as claimed in claim 6 in which gi = g2.
8. User terminal means as claimed in any one of claims 5 to 7 in which the exponent function H incorporates the identity ( DB of the receiving user (B).
9. User terminal means as claimed in any one of claims 5 to 8 in which the exponent function H comprises a one-way, collision-resistance hash function (h).
10. User terminal means as claimed in any one of claims 5 to 8 in which the response RES from the trusted third party (TTP) to a user (B) who wishes to decrypt an encrypted message (e) from a user (A) takes the general form
J,2 HXB2 mod p.
11. User terminal means as claimed in claim 10 which, for a the recipient user (B), is adapted to decrypt the encrypted message (e) to recover the original message (m) using the formulation
Figure imgf000013_0001
12. User terminal means as claimed in claim 11 in which the challenge (CHA) incorporates the identity (IDB) of the recipient user (B).
13. User terminal means as claimed in claim 2 which, for a user (A) wishing to a transmit a signed message (m), is adapted to create a multi-part signature message Sig(m) and to transmit it with the message (m) so that a recipient user (B) can check the signature message Sig(m) against the message (m), the signature message comprising one part (si) generated directly by the user terminal means (TA) for the user (A) so as to encapsulate the user's private key (XA ), and another part (s2) encapsulating the response (RES) received from the trusted third party (TTP) following a challenge (CHA) from the user terminal means (TA).
14. User terminal means as claimed in claim 13 in which the multi-part signature message Sig(m) includes the private parameter (r).
15. User terminal means as claimed in claim 14 in which the private parameter (r) is generated by a public generator function that takes the general form
Figure imgf000013_0002
where gi, g2 and p are public system parameters and p is a large prime integer.
16. User terminal means as claimed in claim 15 in which gi = g2.
17. User terminal means as claimed in any one of claims 13 to 16 in which the challenge (CHA) incorporates the private parameter (r), the identity (IDA) of the transmitting user (A) and the message (m).
18. User terminal means as claimed in any one of claims 14 to 16 in which the response (RES) takes the form gl ~HXH where H is an exponent function that incorporates the private parameter (r), the identity (IDA) of the transmitting user (A) and the message (m).
19. User terminal means as claimed in claim 18 in which the exponent function H is a one-way, collision-resistance hash function (h).
20. User terminal means as claimed in any one of claims 13 to 19 in which the parts (si, s2) of the signature message Sig(m) take the general form
s\ = k\ -HX A mod q and s2 = g2 ~k2RES mod q
where q is a public system parameter in the form of a large prime division of p-1.
21. A cryptosystem comprising one or more user terminal means (TA, TB) as claimed in any one of the preceding claims, and trusted third party means (TTPM) adapted to hold a corresponding private key (XA2, XB2) for each user (A, B), and being responsive to a challenge (CHA) from a user (A, B) by issuing a response (RES) which encapsulates the corresponding private key (XA2, XB2) SO that the user (A, B) can use the response (RES) in combination with the private key (XAX , XBX) already held by the user (A, B) to decrypt or sign a message.
22. A cryptosystem as claimed in claim 21 in which the response RES to a user (B) who wishes to decrypt a message from a user terminal means (TA) takes the general form 7"2 HXB2 mod p, where r2 is a private parameter generated by the user terminal means (TA) and incorporated in the challenge (CHA) to which the trusted third party means responds, and H is an exponent function that incorporates the private parameter r2, and p is a public system parameter in the form of a large primer integer .
23. A cryptosystem as claimed in claim 21 in which the response (RES) to a user terminal means (TA) that wishes to sign a message (m) to a user (B) takes the form
gi "^
where r is a private parameter generated by the user terminal means (TA) and incorporated in the challenge (CHA) to which the trusted third party means responds, and H is an exponent function that incorporates the private parameter (r), the identity (DA) of the transmitting user terminal means (TA) and the message (m).
24. A cryptosystem as claimed in anyone of the preceding claims which comprise two or more trusted third parties means (TTPM), each of which is entrusted with a corresponding private key (Xa2 Xb2 Xa3,Xb3) for each user (A, B), each being adapted to respond to a challenge (CHA) from a user terminal means (TA, TB) by issuing a response (RES) which encapsulates the corresponding private key (Xa2, Xb2, Xa3, Xb3).
25. A cryptosystem comprising two or more trusted third parties means (TTPM) as claimed in claim 7 or 16, each of which is entrusted with a corresponding private key(Z) for each user (A, B), each being adapted to respond to a challenge (CHA) from a user terminal means (TA, TB) by issuing a response (RES) which encapsulates the corresponding private key (X), and the values of two or more of the system parameters (gn) are the same.
26. Trusted third party means for use by a trusted third party in a cryptosystem in which users (A, B) send and receive messages (m) with the help of the trusted third party (TTP) for security purposes making use of private keys (X) and public parameters (P) which encapsulate said private keys (X), each user (A, B) holding a private key (XAX , XBX), the trusted third party means (TTPM) being adapted to hold a corresponding private key (XA2, XB2) for each user (A, B), and being responsive to a challenge (CHA) from a user (A, B) by issuing a response (RES) which encapsulates the corresponding private key (XA2, XB2) SO that the user (A, B) can use the response (RES) in combination with the private key (XAX, XBX) already held by the user (A, B) to decrypt or sign a message.
27. Trusted third party means as claimed in claim 26 in which the response RES to a user (B) who wishes to decrypt a message from a user (A) takes the general form ^2 HXB2 mod p, where r2 is a private parameter generated by the user (A) and incorporated in the challenge (CHA) to which the trusted third party responds, and H is an exponent function that incorporates the private parameter r2, and p is a public system parameter in the form of a large primer integer.
28. Trusted third party means as claimed in claim 27 in which the response (RES) to a user (A) who wishes to sign a message (m) to a user (B) takes the form
-W Λ2 gi
where r is a private parameter generated by the user (A) and incorporated in the challenge (CHA) to which the trusted third party means responds, and H is an exponent function that incorporates the private parameter (r), the identity (IDA) of the transmitting user (A) and the message (m).
29. A method of enabling users (A, B) to send and receive messages (m) with the help of a trusted third party (TTP) for security purposes making use of private keys (X) and public parameters (P) which encapsulate said private keys (X), in which each user (A, B) holds a private key (XAX XBX) and the trusted third party (TTP) is entrusted with a corresponding private key (XA2,XB2) for each user (A, B), the trusted third party (TTP) is adapted so that it is responsive to a challenge (CHA) from a user (A, B) by issuing a response (RES) which encapsulates the corresponding private key (XA2 XB2), and in which the user (A, B) uses the response (RES) in combination with the private key (XAX XB ) already held by the user (A, B) to decrypt or sign a message.
30. A cryptosystem in which users (A, B) send and receive messages (m) with the help of a trusted third party (TTP) for security purposes making use of private keys (X) and public parameters (?) which encapsulate said private keys (X), each user (A, B) holding a private key (XAX ,XBX ) and the trusted third party (TTP) being entrusted with a corresponding private key (XA2,XB ) for each user (A, B), and the trusted third party (TTP) being adapted so that it is responsive to a challenge (CHA) from a user (A, B) by issuing a response (RES) which encapsulates the corresponding private key (XA2,XB2) SO that the user (A, B) can use the response (RES) in combination with the private key (XAI ,XBX ) already held by the user (A, B) to decrypt a received encrypted message (e) or sign a message (m) to be transmitted.
31. A cryptosystem for encrypting messages to be transmitted from a transmitting user (A) to a recipient user (B) and for decrypting received messages with the help of a trusted third-party (TTP), the system making use of at least two private keys for each user, one private key (XB ) being held by the user and the other private key (XB2) being held by the trusted third-party (TTP), each message (m) being encrypted by the transmitting user (A) in accordance with public user parameters (PBX,PB2) that incorporate the private keys (XBX , XB2) of an intended recipient user (B) so that said recipient user (B) can only decrypt the message after a challenge (CHA) to the trusted third party (TTP) and a response (RES) from the trusted third party (TTP) in which the said other private key (XB2) is encapsulated.
32. A signature system for authenticating a message as originating from a user (A) by the user (A) encrypting the message (m) using one or more user encryption parameters (ki, k ) selected by the user (A), and using said user encryption parameters (ki, k2) to generate encapsulated signed messages (si, S2) which are transmitted with the encrypted message (r) to a user (B) to allow authentication of the encrypted message (r) by the user (B) successfully decrypting it, the encapsulated signed messages (si, s2) each incorporating a private key, one private key (XA ) being held by the user (A) and the other private key (XA2) being held by a trusted third-party (TTP) and only being released by the trusted third-party (TTP) in an encapsulated form (RES) when it receives a challenge (CHA) from the user (A).
PCT/GB2003/000202 2002-01-21 2003-01-21 Cryptosystem WO2003063410A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0201282.1 2002-01-21
GB0201282A GB2384406B (en) 2002-01-21 2002-01-21 Cryptosystem

Publications (1)

Publication Number Publication Date
WO2003063410A1 true WO2003063410A1 (en) 2003-07-31

Family

ID=9929429

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2003/000202 WO2003063410A1 (en) 2002-01-21 2003-01-21 Cryptosystem

Country Status (2)

Country Link
GB (1) GB2384406B (en)
WO (1) WO2003063410A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7801302B2 (en) 2004-06-11 2010-09-21 Hewlett-Packard Development Company, L.P. Cryptographic method and apparatus
JP2011508991A (en) * 2007-11-30 2011-03-17 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Key management for secure communication
JP2014099891A (en) * 2014-01-06 2014-05-29 Telefon Ab L M Ericsson Key management for secure communication

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0313666D0 (en) 2003-06-13 2003-07-16 Hewlett Packard Development Co RSA cryptographic method and system
BR0318427A (en) * 2003-07-31 2006-08-01 Thomson Licensing generation and validation of digital signatures diffie-hellman
US7930412B2 (en) 2003-09-30 2011-04-19 Bce Inc. System and method for secure access
GB2415579B (en) 2004-06-23 2006-12-20 Hewlett Packard Development Co Cryptographic method and apparatus
GB2416283B (en) * 2004-07-15 2007-03-07 Hewlett Packard Development Co Trusted authority for identifier-based cryptography
GB2421407A (en) * 2004-12-18 2006-06-21 Hewlett Packard Development Co Generating a shared symmetric key using identifier based cryptography
CA2571814C (en) 2004-12-30 2012-06-19 Bce Inc. System and method for secure access
CN101052033B (en) * 2006-04-05 2012-04-04 华为技术有限公司 Certifying and key consulting method and its device based on TTP

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138236A (en) * 1996-07-01 2000-10-24 Sun Microsystems, Inc. Method and apparatus for firmware authentication
US6076163A (en) * 1997-10-20 2000-06-13 Rsa Security Inc. Secure user identification based on constrained polynomials
US7237114B1 (en) * 2000-04-26 2007-06-26 Pronvest, Inc. Method and system for signing and authenticating electronic documents

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BLAZE M ET AL: "Divertible protocols and atomic proxy cryptography", ADVANCES IN CRYPTOLOGY- EUROCRYPT. INTERNATIONAL CONFERENCE ON THE THEORY AND APPLICATION OF CRYPTOGRAPHIC TECHNIQUES, SPRINGER VERLAG, DE, 31 May 1998 (1998-05-31), pages 127 - 144, XP002127731 *
IVAN A, DODIS Y: "Proxy Cryptography Revisited", DEPARTMENT OF COMPUTER SCIENCE, COURANT INSTITUTE OF MATHEMATICAL SCIENCES, NEW YORK UNIVERSITY, January 2003 (2003-01-01), New York 10012, USA, pages 1 - 19, XP002237307 *
PETERSEN H ET AL: "SELF-CERTIFIED KEYS - CONCEPTS AND APPLICATIONS", COMMUNICATIONS AND MULTIMEDIA SECURITY. INTERNATIONAL CONFERENCE, XX, XX, vol. 3, September 1997 (1997-09-01), pages 102 - 116, XP000828383 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7801302B2 (en) 2004-06-11 2010-09-21 Hewlett-Packard Development Company, L.P. Cryptographic method and apparatus
JP2011508991A (en) * 2007-11-30 2011-03-17 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Key management for secure communication
JP2014099891A (en) * 2014-01-06 2014-05-29 Telefon Ab L M Ericsson Key management for secure communication

Also Published As

Publication number Publication date
GB0201282D0 (en) 2002-03-06
GB2384406A (en) 2003-07-23
GB2384406B (en) 2004-05-12

Similar Documents

Publication Publication Date Title
US10530585B2 (en) Digital signing by utilizing multiple distinct signing keys, distributed between two parties
EP1066699B1 (en) Method of generating a public key in a secure digital communication system and implicit certificate
US5796833A (en) Public key sterilization
US6058188A (en) Method and apparatus for interoperable validation of key recovery information in a cryptographic system
US7657037B2 (en) Apparatus and method for identity-based encryption within a conventional public-key infrastructure
Toorani et al. An elliptic curve-based signcryption scheme with forward secrecy
CN107659395B (en) Identity-based distributed authentication method and system in multi-server environment
CN110113150B (en) Encryption method and system based on non-certificate environment and capable of repudiation authentication
WO2003063410A1 (en) Cryptosystem
JP4307589B2 (en) Authentication protocol
JP2023505629A (en) Method and system for verifiable identity-based encryption (VIBE) using certificateless authentication encryption (CLAE)
Elkamchouchi et al. An efficient proxy signcryption scheme based on the discrete logarithm problem
Om et al. Comment and modification of RSA based remote password authentication using smart card
Andreevich et al. On Using Mersenne Primes in Designing Cryptoschemes
JP4146252B2 (en) Anonymous communication method capable of identifying unauthorized persons, user device used in the method, and relay server device
JP3862397B2 (en) Information communication system
CN114785487A (en) Anti-quantum computation HTTPS communication method and system based on CA and Guomu&#39;s cipher algorithm
Lim et al. Secure deniable authenticated key establishment for internet protocols
Ganjewar Diffie Hellman Key Exchange
Shivakrishna et al. Hash Algorithm Based A New Secret Key Agreement Algorithm
Oh et al. An Efficient Hybrid Cryptosystem Providing Authentication for Sender’S Identity
Stickel Public-Key Cryptography
Bob What Crypto Isn't
JPH04297156A (en) Method and device for cipher communication

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP