Java, J2EE & SOA Certification Training
- 40k Enrolled Learners
- Live Class
Encryption is the method of using mathematical algorithms to camouflage the meaning of a piece of information so that only authorized parties can decipher it. In this article, we will discuss Encryption and Decryption in Java in the following order:
Encryption is implemented to protect our data (like texts, conversations ad voice), be it sitting on a computer or it is sent on the Internet. Recent encryption technologies are essential elements of any secure computing environment.
The primary role of security of encryption lies in the capability of an algorithm to generate ciphertext (encrypted text) which is tough to revert to its original plaintext. The usage of keys also creates another level of security to methods of protecting our information. A key is some information, which allows only those that hold it to encode and decode a message.
The Symmetric algorithms utilize the same key for encryption and decryption. Such algorithms can only operate in block mode (which works on fixed-size blocks of data) or stream mode (which works on bits or bytes of data). Such algorithms are also commonly used for applications like data encryption, file encryption and encrypting transmitted data in communication networks (like TLS, emails, instant messages, etc.)
Unlike symmetric algorithms, which utilize the same key for both encryption and decryption operations, the asymmetric algorithms use two identical keys for these two steps. These algorithms are utilized for computing digital signatures and key establishment protocols. However, this also comes with a challenge that two keys need to be used which makes things more complex.
In order to configure any basic encryption scheme safely, it is very crucial that all such parameters (at the minimum) are designed correctly:
It is very crucial to be aware of configuring all of these parameters securely. Even a tiny misconfiguration can jeopardize an entire crypto-system and open it to attacks from hackers and other malware. Hence, to keep this discussion simple, let us discuss only algorithm-independent initializations of a Cipher. Instead of doing such encryptions by yourself, it is always better to let experts do their job of configuring more algorithm-dependent configurations, like p and q values of the RSA algorithm, etc. By just configuring the rudimentary cryptographic parameters above more than half a dozen, classes are used.
The introduction of class hierarchies, plenty of overloaded constructors/methods and so on, adding many complexities, which make It unnecessary. I wish Java did not complicate the basic configurations and would simply employ a more simplified architecture like that of Microsoft, where all such parameters are within the perimeter of a single class SymmetricAlgorithm and AsymmetricAlgorithm. For the first three parameters to be specified (algorithm, mode of operation and padding scheme), a Cipher object utilizes a transformation string.
A transformation string undoubtedly includes the name of a cryptographic algorithm. Between symmetric and asymmetric encryption, there are 11 algorithms (not regarding various PBEWith<digest|prf>And<encryption> combinations), which can be specified as per the Standard Algorithm Name Documentation. Out of them only two (one for each, symmetric and asymmetric encryptions) are actually fully secured.
The remaining algorithms are either excessively broken (DES, RC2, etc.) or cracks have started to surface (RC5), making it breakable with sufficient CPU power – it can be already broken by the time you read this. A security-minded developer may not read troves of NIST specifications, nor follow the latest happenings and research in the cryptography community. They might pick up the broken or risky algorithms, digest or pseudo-random generator.
Symmetric Algorithm: AES/AESWrap block cipher is used.
Asymmetric Algorithm: RSA is used.
The mode of operation is a part of the transformation and is only relevant to block ciphers. When we use asymmetric ciphers, use ECB as the mode of operation, which essentially is a hack behind-the-scenes, meaning ignore this value. The Java providers like SunJCE, SunPKCS11 defaults to ECB mode for symmetric and asymmetric algorithms. It may be a good thing for asymmetric algorithms, but a bad idea for block ciphers.
The providers could be instructed to make secure defaults based on the algorithm used. Use symmetric encryption to save you from replay attacks or known-plaintext attacks. Also, use a transformation, which fully specifies an algorithm (i.e. with its mode of operation and padding). Never, ever do something like the one mentioned below.
As above, the AES algorithm would be utilized with ECB mode of operation, making replay attacks very easy. For new development, if there is the slightest possibility of revamping old work, we should use authenticated encryption with associated data (AEAD) mode (For example GCM and CCM). We have an authentication tag with a full 128 bits-length. If we use an unauthenticated mode we use CBC or CTR with a MAC to authenticate the ciphertext.
The common block cipher modes need the length of plain text to be a multiple of the block size of the underlying encryption algorithm, which is seldom the case. Thus, we require some padding. Java program provides us three different schemes for symmetric encryption, one being No Padding, which is unacceptable, and another being ISO10126Padding that is withdrawn since 2007).
Therefore, the only suitable option is using PKCS5Padding. The mixture of some modes of operation (for example CBC mode) and PKCS5Padding padding scheme can lead to padding oracle attacks. Not mentioning a padding scheme at all is more dangerous than providing a scheme that is susceptible only to certain types of attacks. AEAD mode of operation is most recommended to be sure that you be protected against these attacks.
In asymmetric algorithms, we have the option of choosing from two padding schemes. It is important to ensure that only OAEPWith<digest>And<mgf>Padding schemes are used. In case of a digest, please use either SHA1 or SHA256/384/512. For the Mask Generation Function (MGF), please utilize the MGF1 padding as specified. PKCS1Padding with RSA has been vulnerable to Ciphertext attacks since 1998.
Here we talk about the correct way to use a transformation in a “Cipher.getInstance” method.
A security level of any encryption scheme is directly proportional to the size of its key. The key length must be long enough that whatever brute force attacks it becomes unfeasible at the same time it should also be short enough to keep computational feasibility in mind. In addition, we must try to consider what still withstand computational advances for the next 30 years.
With this, we come to the end of Encryption in Java article. I hope you got an idea of Encryption and Decryption and why it is used in Java.
Check out the Java training by Edureka, a trusted online learning company with a network of more than 250,000 satisfied learners spread across the globe. Edureka’s Java J2EE and SOA training and certification course is designed for students and professionals who want to be a Java Developer. The course is designed to give you a head start into Java programming and train you for both core and advanced Java concepts along with various Java frameworks like Hibernate & Spring.
Got a question for us? Please mention it in the comments section of this “Encryption in Java” blog and we will get back to you as soon as possible.