Frequently Asked Questions

The first thing recommended to do is to call IAIK, you might even try to call late, as somtimes we are working overtime.
We have made the experience, that many questions occuring are answered by

a) reading the documentation or

b) looking into the mailinglist archives or

c) searching our Newsgroup .

If you still can't solve your problem, try our Newsgroup, maybe somebody else can answer your question easily. Our staff is also monitoring that list and we try to help if time allows. For motivating us, you also can buy support - and if you have bought one of our toolkits you already might be owning support-points you can make use of. Calling us by phone is only a good option if you subscribed to a support-plan that allows you to do so. Otherwise, we may reject to answer your call and direct you to one of our electronic forms of support. If you think you have found a bug, please use our bug-report-form !

Yes, use our JSSE wrapper as interface to the JSSE framework.

Yes. See our info about iSaSiLk and Smartcards.

The constructor of a SSLContext creates a new default Java™ SecureRandom object. On some platforms this process may take a very long time. There are two possible solutions to this problems:

1. Immediately after starting your application, create a new thread which initiates the SecureRandom generator. When you need the first random number the seed has already been generated:

    // create a new Thread which initializes the Secure Random Number generator
    (new Thread() {
      public void run() {
        setPriority(Thread.MIN_PRIORITY);
        SecRandom.getDefault().nextInt();
      }
    }).start();

2. Write your own Seed Generator which creates a true random seed in a faster way.

You could ask at Prentice Hall ,  O´Reilly , or John Wiley & Sons , e.g.: William Stallings : Cryptography and Network Security: Principles and Practice , 2/e ,
Published  in June, 1998 by Prentice Hall Engineering, Science & Math (June, 1998) Marcus Goncalves: Protecting Your Website With Firewalls , 1/eMarcus Goncalves: Protecting Your Website With Firewalls , 1/e
Published April, 1997 by Prentice Hall Professional Technical Reference Raymond R. Panko: Business Data Communications and Networking: A Modular Approach , 2/e
Coming November, 1998 from Prentice Hall Business Publishing Jonathan B. Knudsen : Java Cryptography
Published by O´Reilly, 1st Edition May 1998 Scott Oaks : Java Security
Published by O´Reilly, 1st Edition May 1998 Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Ed.
Published by John Wiley & Sons, Oct 1995 Peter Lipp, Dieter Bratko, Johannes Farmer, Wolfgang Platzer, Andreas Sterbenz: Sicherheit und Kryptographie in Java , 2000 by Addison Wesley Deutschland

It is a problem with the JIT of JDK1.1.6. Try to use the JVM option -nojit till the bug is fixed.
Testing the application CipherSuiteTest we found the following problems:

• JDK 1.1.6 JIT: o.k.
• JIT EA1: o.k.
• JIT EA2: not o.k.

You are right. According to the SSL 3.0 specification, a client also can start renegotiating the active cipher suite by sending a new client_hello message. Starting with iSaSiLk snapshot isasilk.2.01, it also will be possible to initiate a cipher suite renegotiation from the client side. The syntax will be the same as forcing a renegotiation from the server side: just call the renegotiate() method of the SSLSocket class for sending a client_hello message to restart the handshake procedure:

When  calling renegotiate() from the server side, first a hello_request message will be sent to the client, indicating to the client that he can start a new handshake dialogue by transmitting a client_hello message.

Renegotiating a cipher suite works this way:

1. A client connects to a server -
   handshaking procedure is performed -
   SSL connection is OK -
   client and server can exchange data
2. Now the server can force a renegotiation of the cipher suit by sending a "Hello Request" handshake message to the client.
3. The client receives the "Hello Request" handshake message and starts a
   complete new handshaking procedure by sending the first message, the "Client
   Hello" message.

The only difference is that the handshake messages of this second handshaking procedure are already protected according to the cipher suite which was negotiated by the first handshaking procedure. So an attacker cannot even see the normal unencrypted hello and key exchange messages.
 
The server may initiate a renegotiation by refreshing the (cipher suite) settings of the SSLContext belonging to the SSLSocket (returned by the accept() method at the beginning of the on-going session) that is used for communicating with the actual client. Then the server starts the renegotiation by means of the SSLSocket´s renegotiate() method:

iSaSiLk 3.0 includes a demo SSLServer also dealing with cipher suite renegotiation.