JAVA-BASED CRYPTOGRAPHIC PROVIDER FOR ITKIS-REYZIN
FORWARD-SECURE SIGNATURE ALGORITHM
Abstract
Itkis-Reyzin Signature Scheme is the first practical forward-secure signature
algorithm for which both signing and verifying are as efficient as for one of the most
efficient ordinary signature schemes (Guillou-Quisquater), each requiring just two
modular exponentiations with a short exponent. The scheme requires only fractional
increases to the sizes of keys and signatures, and no additional public storage is needed.
We developed a Java-based test implementation of Itkis-Reyzin algorithm [IR01]
demonstrating its applicability for the real-life cryptographic solutions. We also have
measured and evaluated the efficiency of its major functions (Key Generation, Signing,
Verification, and Key Update) and compared the algorithm’s performance to the
performance of other standard signature schemes. Our benchmark tests show that our
performance measurements agree to the theoretical estimates made by the authors: while
Key Generation part is moderately slow as compared, for instance, to RSA signature
scheme, Signing and Verification times are quite small for 1024-bit keys, and the Key
Update function, invoked only once every time period, has a good practical efficiency.
IMPLEMENTATION SETUP
We developed our cryptographic provider using open source Cryptix 3 Java cryptography
toolkit (www.cryptix.org) for Java 2 SDK 1.3 and tested it on IBM NetVista Pentium III
930 Mhz workstation with 391,600 KB RAM under Windows 2000 Professional Edition
(command line mode). Our demo program allows generating 512-bit keys, signing a
message of user’s choice for the given period of time, and verifying the signature for a
given message. For our demo program we limited the number of time periods to 16, but it
could be easily increased to any arbitrary integer number depending on the application’s
needs (to simplify the calculations it has to be a power of two).
INTRODUCTION
It is a well-known fact that ordinary digital signatures have an inherent weakness: if the
secret key is leaked, then all signatures, even the ones generated before the leak, are no
longer trustworthy. This weakness undermines the non-repudiation property that is usually
associated with digital signatures. To address this issue “forward-secure” digital signatures
were introduced in the recent years [And97, BM99, AR00, Kra00]. Among the first
forward-secure signature schemes for which both Signing and Verifying routines are fast is
Itkis-Reyzin (IR) signature algorithm [IR01]. It is as efficient as its underlying ordinary
signature scheme, due to Guillou-Quisquater [GQ88]. The space requirements for the keys
and signatures are nearly the same as those of GQ scheme. The price of such efficient
signing, verifying and storage is the running times of Key Generation and Update
functions. However, these functions are presumably less frequently performed than Signing
and Verifying, and very easily can be done off-line to improve overall performance. In
addition, the IR scheme is provably secure in the random oracle model based on a variant
of strong RSA assumption.
DESCRIPTION OF THE ALGORITHMS
Here we present a short description of Itkis-Reyzin algorithm that we implemented. The
detailed discussions of the functions and proofs of their security can be found in [IR01].
Class IRAlgorithm.java contains all 4 functions used in our implementation. The following
pseudo-code illustrates the structure of these functions:
Algorithm IR.key(k, l, T)
- Key Generation
k – size of the key, l- security parameter, T- number of time periods
Generate random ( k/2 - 1)-bit primes q1, q2 s.t. pi = 2qi + 1 are both prime
n  p1p2
t1  random from Zn*
Generate primes ei s.t. 2l( 1 + (i - 1)/T)  ei < 2l(1+i/T) for i = 1, 2, …, T.
(this generation is done either deterministically or using a small seed seed and H as
pseudorandom function.)
f2  e2… eT mod (n) = 4q1q2
s1  t1f2 mod n
v  1/s1e1 mod n
t2  t1e1 mod n
SK1  (1, T, n, s1, t2, e1, seed)
PK  (n, v, T)
return (SK1, PK)
Algorithm IR.update(SKi)
- Update
SKi - secrete key for time period i
Let SKj = (j, T, n, sj, tj+1, ej, seed)
If j = T then return 
Regenerate ej+1, …..eT, using seed
sj+1  t mod n; tj+2ej+1 
mod n
return SKj+1(j+1, T, n, sj+1, tj+2, ej+1, seed)
Algorithm IR.sign(M, SKj)
- Signing
M – message, SKj - secrete key for time period j
Let SKj = (j, T, n, sj, tj+1, ej, seed)
r  rand Zn*
y  rej mod n
  H(j, ej, y, M)
z  rs mod n
return (z, , j, ej)
Algorithm IR.vf(M, PK, (z, , j, e)) - Verifying
M – message, PK - public key, (z, , j, e) – signature for the time period j
Let PK = (n, v)
if e  2l (1 + j/T) or e < 2 l or e is even then return 0
if z  0 (mod n) then return 0
y  zev mod n
if  = H(j, e, y, M) then return 1 else return 0
THE DESIGN OF OUR CRYPTOGRAPHIC PROVIDER
We modeled the structure of our provider according to Cryptix conventions for signature
algorithms and many parts contain original Cryptix code amended for our needs. In fact we
just added the new algorithm called “IR” to the list of algorithms made available by
Cryptix provider. However, our implementation is intended for demonstration purposes
only, and not for commercial use. The Cryptix 3.2.0 JCE should be installed and added as a
cryptographic provider in java.security file prior to running our Demo program in the
following way:
#
# List of providers and their preference orders (see above):
#
security.provider.1=cryptix.provider.Cryptix
security.provider.2=sun.security.provider.Sun
security.provider.3=com.sun.rsajca.Provider
Note that Cryptix should be added as the fist provider in the list! The presence of other
providers in the list is allowed, but not necessary to run the Demo.
CLASSES AND INTERFACES USED IN THE IMPLEMENTATION
The following classes belong to cryptix.provider.ir package we added to the Criptix
provider:
Any_IR_PKCS1Signature.java
An abstract class to digest a message and sign/verify the resulting hash value, using any
JCA MessageDigest algorithm with the IR digital signature scheme.
MD5_IR_PKCS1Signature.java
A class to digest a message with MD5, and sign/verify the resulting hash using the IR
digital signature scheme. It extends Any_IR_PKCS1Signature class.
BaseIRKeyPairGenerator.java
A class that extends JCA’s KeyPairGenerator class, and is capable of generating IR key
pairs. The generator is first initialized, and then used to generate one or more IR key pairs.
BaseIRPrivateKey.java
An abstract class representing an IR private key. It implements CryptixIRPrivateKey
interface.
BaseIRPublicKey.java
An abstract class representing a IR public key. It implements CryptixIRPublicKey
interface.
RawIRPrivateKey.java
A class representing IR private key to be made from several “raw” components.
RawIRPublicKey.java
A class representing IR public key to be made from several “raw” components.
IRAlgorithm.java
A class that calculates the IR algorithm. It contains ir_sign(…), ir_verify(…), and
ir_update(…) functions used in the algorithm. The Key Generation part is located in
BaseIRKeyPairGenerator class.
Cryptix.properties
This original Cryptix file contains aliases to the different algorithm names used in Cryptix
provider. We added the following lines to this list:
Alg.Alias.Signature.MD5/IR =
MD5/IR/PKCS#1
KeyPairGenerator.IR =
cryptix.provider.ir.BaseIRKeyPairGenerator
Signature.MD5/IR/PKCS#1 =
cryptix.provider.ir.MD5_IR_PKCS1Signature
GUI CLASSES
The following classes are located in `/src/cryptix/test directory and are the parts of
cryptix.test package:
Demo.java
Main file contaning GUI for testing the IR algorithm.
QuitDialog.java
Auxiliary GUI file to Demo.java to make an additional Quite Dialog panel.
AboutDialog.java
Another auxiliary GUI file containing About information for the Demo program.
GenKeys.java
Class contains the key generation part for the Demo.
SignMessage.java
Class contains the signing part for the Demo.
Verify.java
Class contains the verifying part for the Demo.
INTERFACES ADDED TO THE PACKAGE xjava.security.interfaces:
CryptixIRPrivateKey.java
The interface to an IR private key. It extends IRKey and PrivateKey interfaces.
CryptixIRPublicKey.java
The interface to an IR public key.
IRKey.java
The superinterface to an IR public or private key interfaces.
IRKeyPairGenerator.java
An interface to an object capable of generating IR key pairs. The generator is first
initialized, then used to generate one or more key pairs.
PERFORMANCE RESULTS
We have got different performance results when we tested our implementation on
different standalone systems. Here we will report the results only for one particular testing
setup described above. The system was very lightly loaded by other processes. We also
would like to note that the results might have been different, had we implemented IR
algorithms using “faster” programming languages like C or C++.
Our tests show that it takes more time for the Java interpreter to answer the very
first Key Generation, and Key Update requests, since it initially loads some routines from
disk into the memory before processing these queries. All consequent requests are
performed much faster since all the necessary data is supposedly already in cache memory.
The processing of a single 1025-bit Key Generation request for our test setting takes
approximately from 6-7 minutes, depending on probabilistic prime generation part,
whereas the Generation part for RSA usually takes about 7-10 seconds. All next Key
Generations are usually significantly reduced (tens of times faster). Since Key Generation
part is performed only once and can be easily made off-line on a cryptographic server, this
slowdown is not very important: it is inevitable trade-off between Generation time and
improved level of security. At the same time, the online Signing part for IR takes on
average 29-30 ms/signature for 1000 signatures with 1024-bit keys, and it takes about 34
ms/signature for RSA. Analogously, the Verifying part takes on average about 27-28
ms/signature for IR and about 1-2 ms/signature for RSA, if a constant exponent e is used.
The invocation time of Update function in IR depends on the number of time periods T,
and can be sped up using different techniques detailed in [IR01]. In our implementation we
used the most straightforward Update algorithm without any speedups. Since the Update
time decreases with each passing time period, we measured just the longest Update time for
the second time period. For example it takes about 18,000 ms to update the key if the total
number of time periods T is equal to 512, and only about 800 ms, if T is equal to 16.
REFERENCES
[And97]
Ross Anderson. Invited lecture. Fourth Annual Conference on Computer
and Communications Security, ACM, 1997.
[AR00]
Michel Abdalla and Leonid Reyzin. A new forward-secure digital signature
scheme. In Advances in Cryptology - ASIACRYPT 2000, Springer-Verlag,
2000. Full version available from the Cryptology ePrint Archive, record
2000/002, http://eprint.iacr.org/.
[BM99]
Mihir Bellare and Sara Miner. A forward-secure digital signature
scheme. In Advances in Cryptology - CRYPTO '99, Springer-Verlag, 1999.
Revised version is available from http://www.cs.ucsd.edu/mihir/.
[GQ88]
Louis Claude Guillou and Jean-Jacques Quisquater. A “paradoxical"
indentity-based signature scheme resulting from zero-knowledge.
In, Advances in Cryptology - CRYPTO '88, volume 403 of Lecture Notes in
Computer Science. Springer-Verlag, 1990, pages 216-231.
[IR01]
Gene Itkis and Leonid Reyzin. Forward-Secure Signatures with Optimal
Signing and Verifying, In Advances in Cryptology - CRYPTO 2001,
Springer-Verlag, 2001.
[Kra00]
Hugo Krawczyk. Simple forward-secure signatures from any signature
scheme. In Seventh ACM Conference on Computer and Communication
Security. ACM, November 1-4, 2000.