| | As a bit of background, private-key cryptography uses a secret key for both encryption and decryption. The algorithm employs several iterations, referred to as rounds. Each round uses a subkey derived from the key. The transformation from plaintext to ciphertext and vice versa uses the subkey and progresses through the rounds. The selection or generation of subkeys is referred to as the key schedule. | By using application metadata, wise developers can accomplish a similar feat. Metadata, or data about data, describes software in an external and fluid manner that replaces internal hardcoded constants. By stashing those details in a separate editable text file, you allow yourself and other users/developers to drastically alter application behavior without writing new code. The metadata deployment descriptors of Java Enterprise applications testify to that flexibility. Take a look at the following increasingly sophisticated uses of metadata and consider how you might add the technique to your own coding repertoire. | Symmetric or "single key" encryption is a good choice for solving this type of problem. Single key encryption uses the same key to encrypt and decrypt data. DES and DESede are two single key encryption schemes. I will show you how to solve this problem using either of these encryption schemes with the JCE. | Internet distribution Consider the case of a software package distributed over the Internet. Software packages available through ftp were, in the recent past, associated with checksums. The idea was to download the software, then run a program to calculate your version of the checksum. The self-calculated checksum could then be compared to the checksum available on the ftp site to make sure the two matched and ensure data integrity (of sorts) over the wire. The problem is this old-fashioned approach is not cryptographically sound. For one thing, with many checksumming techniques, modifying the program to download maliciously, while causing the modified program to yield the exact same checksum is possible. For another, a "Trojaned" version of a software package can easily be published on an ftp site with its associated (poorly protected) checksum. Cryptographic hash functions can be used as drop-in replacements for old style checksum algorithms. They have the advantage of making tampering with posted code extremely difficult. | In this tutorial, you'll employ the open standard Bouncy Castle to encrypt mobile MIDlet applications. The tutorial provides an overview of how to encrypt application-related data in a Java 2 Micro Edition (J2ME) application. It begins with a brief introduction to data encryption, then continues on to introduce the open source obfuscator, ProGuard. The final section in this tutorial compares MIDlet JAR file sizes, with and without obfuscation. | This article assumes that you are familiar with the concepts behind the Atom syndication format. You should also have at least a passing familiarity with the concepts behind XML security, though this isn't strictly necessary. | A complete listing of the encryption algorithms, modes, and padding schemes available within the Sun JCE can be found in the Java Cryptography Extension Reference Guide, Appendix A, at http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html#AppA. | | Message authentication is necessary in situations where a message recipient must be guaranteed that the message he received was the one the sender sent. Here, you have learned how to create and verify MACs using the Java Cryptography Extensions. Using the techniques discussed here, you now have the tools to create a secure message exchange between a sender and a recipient, even when the message must pass through unsecured channels. | The programs that I will provide to perform this operation have not been optimized for efficiency. Rather, they were written for instructional purposes only. As mentioned earlier, you should not attempt to use these programs for production cryptography. If you need a Java program to do public-key cryptography, you should develop that program using Sun's Java Cryptography Extension. | Java programs can simply request a particular cryptographic object or implement a particular cryptographic service. They can also ask for a specific provider by name or by the name and service. As mentioned before, providers have a preference order, and new providers can be added statically and dynamically. The idea behind the cryptography extension is to remove the programmer from the math and complexity involved in algorithms, and instead utilize provider classes that take care of the implementation. This way, different providers can implement algorithms that are software based, or hardware based. They can also implement platform-specific or platform-dependent algorithms. | The JCE removes users from the implementation of cryptography, and the algorithms involved, making both easy to use. A programmer can specify algorithms, or the JCE architecture will choose the default algorithms. The JCE uses a provider based architecture, based on using Cryptographic Security Providers (CSPs). An application that uses an object that needs a specific CSP service or algorithm will run through the installed providers, and choose the first default provider with an appropriate service. Alternately programmers can choose specific providers for specific services. | The longest and most difficult part of setting up a provider is actually writing the algorithm-specific code implementations of the services you want to provide. For each service provided, a subclass of the appropriate SPI class needs to be created (i.e., SignatureSpi). In your subclass, you need to supply implementations for the abstract methods (usually an engine) and ensure there is a public constructor without any arguments. | With the new JCE 1.2.1, customizing securitymanager may be necessary in order to properly implement your provider. Sun also asks that providers carefully document services for users, and although JCE 1.2.1 hallmarks availability of these cryptography tools outside of the United States, implementing them in this way adds a layer of complexity. |
|