Browse Prior Art Database

Method for RSA Key Agreement

IP.com Disclosure Number: IPCOM000118330D
Original Publication Date: 1996-Dec-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 103K

Publishing Venue

IBM

Related People

Johnson, DB: AUTHOR [+2]

Abstract

In ANSI X9.42, the Diffie-Hellman key agreement algorithm is used to establish a shared secret between communicating parties. After the shared secret is established, it can be used to spawn symmetric algorithm keys (e.g., DES keys) by concatenating a counter and other public information to the shared secret and passing the result through a strong cryptographic one-way hash function. In this disclosure, these capabilities of the Diffie-Hellman algorithm are extended to the RSA algorithm.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for RSA Key Agreement

      In ANSI X9.42, the Diffie-Hellman key agreement algorithm is
used to establish a shared secret between communicating parties.
After the shared secret is established, it can be used to spawn
symmetric algorithm keys (e.g., DES keys) by concatenating a counter
and other public information to the shared secret and passing the
result through  a strong cryptographic one-way hash function.  In
this disclosure, these  capabilities of the Diffie-Hellman algorithm
are extended to the RSA algorithm.

      Recall that in a Diffie-Hellman (DH) key agreement, someone
typically calculates a large prime P and a generator G for a network
of users.  User A in the network generates a random number XA and
keeps it a secret.  User A calculates YA = G**XA mod P.  YA is user
A's public DH key which is then published or distributed to
interested parties.  User B does the same, except the values are XB
and YB.  If user A and user B want to exchange information securely,
they each locate the other's public key.  User A calculates the DH
Shared Secret (SS) as YB**XA mod P.  User B calculates the DH SS as
YA**XB mod P.  SS should be the same value on both systems.  Both
users can then concatenate additional public information, such as a
time stamp, etc.  and/or a counter to the SS and run the result
through a one-way function to produce a value that is interpreted as
a symmetric key, e.g., a DES key which can be used to encrypt
messages between A and B.  If more keys are needed, then the counter
can be incremented or additional public information be exchanged and
put into the calculation of another symmetric key.

      RSA is used for key transport in ANSI X9.44, typically as
follows:  User A calculates 2 large primes P and Q, sets the modulus
NA = P times Q, sets the public exponent EA to some value, e.g., 3,
2**16+1 or random, and calculates the private exponent DA so that
(X**EA)**DA MOD NA = X for all XA < NA.  The calculation of DA is
straightforward if P and Q are known but is very difficult if only NA
and EA are known.  User A distributes NA and EA to interested
parties, e.g., in a public key certificate.  User B does similar
calculations and gets NB, EB, and DB and distributes NB and EB.  For
user A to transport a key to user B, user A generates a random value
that will be interpreted as a symmetric key K, formats and encrypts
it using user B's public key as follows:  Format(K)**EB mod NB and
sends the result to B.  To show this value is from him, user A can
sign the above quantity and/or can place an indication in the
formatted form as to the fact that this is from user A.  User B
recovers the key K by (Format(K)**YB mod NB)**XB mod NB and recovers
Format(K), verifies it, and recovers K.  User B can now use key K to
recover (e.g.) encrypted messages sent from user A.  However, user B
may not desire to use key K to encrypt messages for user A as this
REQUIRES user B to trust the random n...