- Example Programs and crypttool
- Cryptographic Services and Providers
- Cryptographic Keys
- Encryption and Decryption
- Message Digest
- Message Authentication Code
- Digital Signature
- Key Agreement
- Summary of Cryptographic Operations
- Cryptography with crypttool
- Limited versus Unlimited Cryptography
- Performance of Cryptographic Operations
- Practical Applications
- Legal Issues with Cryptography
- Summary
- Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Cryptography with crypttool
While writing this book, I strongly felt the need for such a tool that could allow me to carry out the cryptographic operations without writing code and not finding one, wrote crypttool, a command line utility to carry out common cryptographic operations. This tool is patterned after keytool, a command line utility bundled with J2SE for generating public and private key pairs and managing certificates. In a number of ways, crypttool complements keytool by providing additional functionality to a Java developer.
Here is a brief description of how crypttool operates: it accepts a command name and other input as command line options, carries out the operation and writes the result to the standard output. You can get a listing of all the supported commands with brief descriptions by invoking "crypttool help". Command specific options and other details can be displayed by executing "crypttool <cmd> help". Refer to the appendix JSTK Tools for a complete listing of commands and their options.
Let us have a brief session with crypttool. This also gives us an opportunity to recapitulate all the operations that we have covered in this chapter.
The first step is to generate a secret key using DESede or TripleDES algorithm and save the generated key in a file. This key will later be used for encryption/decryption and computing the MAC of data in a file.
C:\jstk>bin\crypttool genk -action save -file test.sk \ -algorithm DESede -keysize 112 SecretKey written to file: test.sk
Execution of this command takes a while—around 7 seconds on a 900 MHz. AMD Athlon machine running Windows 2000. This is primarily due to initialization overhead for secure random number generator. J2SE v1.4.1 has optimized this step for the Windows platform and the corresponding time is less than 4 seconds, which is still noticeably slow. Get used to the slow start for standalone programs that use cryptography. Thankfully, the subsequent operations in the same JVM are much quicker.
What gets written to the file test.sk is not the raw bits of the generated key but the serialized Java object of type SecretKey. If you want to see the raw bits in hex format, use—action print instead of –action save in the crypttool invocation. You may also want to try other algorithms and keysizes supported in your environment.
Let us use the generated key to encrypt a file and then decrypt the encrypted file. We will use DESede algorithm in CFB8 mode, matching the algorithm of key generation.
C:\jstk>bin\crypttool crypt -op enc -infile build.xml –outfile \ test.enc -keyfile test.sk -iv 12345678 -transform \ DESede/CFB8/NoPadding encrypted file "build.xml" to "test.enc" C:\jstk>bin\crypttool crypt -op dec -infile test.enc \ –outfile test.dec \ -keyfile test.sk -iv 12345678 -transform \ DESede/CFB8/NoPadding decrypted file "test.enc" to "test.dec"
Note that padding is not required as CFB8 mode operates on 8-bit blocks. Other modes such as CFB32 or CBC would require a padding scheme such as PKCS5Padding. Also note the use of initialization vector by specifying –iv option. The string specified as the initialization vector is converted into a byte array by crypttool. If you do not specify an initialization vector for encryption then the underlying implementation will supply one. You must specify the same value for decryption.
Le us compare the decrypted file with the original file.
C:\jstk>comp test.dec build.xml Comparing test.dec and build.xml... Files compare OK
As expected, the decryption retrieves the original content.
You could use this command to encrypt sensitive information on disk or attachments that must be sent over the Internet. In such situations, use of a secret key, an initialization vector and a specific transformation scheme could be cumbersome. A better method is to use a password based encryption as per PKCS#5 standard. This is supported by Java and also by crypttool. Just replace the –keyfile, -iv and –transform options with –password option followed by the password. By default, PBEWithMD5AndDES algorithm is used for encryption and decryption.
C:\jstk>bin\crypttool crypt -op enc -infile build.xml \ –outfile test.enc -password changeit encrypted file "build.xml" to "test.enc" C:\jstk>bin\crypttool crypt -op dec -infile test.enc \ –outfile test.dec -password changeit decrypted file "test.enc" to "test.dec"
Our next task is to generate a key pair, use the private key to sign a document and the public key to verify the signature.
C:\jstk>bin\crypttool genkp -action save -file test.kp KeyPair written to file: test.kp C:\>crypttool sign -infile build.xml -keyfile test.kp \ -sigfile build.sig signature written to file: build.sig C:\>crypttool sign -verify -infile build.xml \ –keyfile test.kp -sigfile build.sig verification succeeded
By default, crypttool uses the DSA algorithm with a key size of 512 bits to generate key pair and SHA1withDSA algorithm for signature. Also, it knows to pick the private key for signature creation and public key for verification from a file having a serialized KeyPair object. In a real application, though, one would keep them in separate files and in a format understood by widely used programs. The private and public keys are typically stored in a keystore with the private key protected by a password and the public key embedded in a certificate. crypttool can pick up private and public key from a keystore as well.
Use of crypttool to compute message digest and MAC is left as an exercise.