COMP2300 Computer Organisation And Program Execution
Question about COMP2300
This assignment will make use of the theory taught in the first four weeks’ and will teach you how file encryption is performed in reality using the standard cryptoprimitives provided in the Java Cryptography Architecture. Along the way, you’ll explore issues such as padding, block cipher modes and how to generate large, reasonably random keys from passwords (or, better still, passphrases).
You can split this task into three easy stages to allow you to check your work, and as you proceed, Download the file FileEncryptor.java from iLearn and import it into an Eclipse Java project called FileEncryptor so that you can work on it.
Get BTEC HND Assignment help now !!
FileEncryptor.java is the skeleton of a simple file encrypt/decrypt program. On the command line, the first parameter is “E” or “D” for encrypt or decrypt, respectively, while the second and third parameters are the input file and output file, as you’d expect. However, the fourth parameter is not a key, but a password or passphrase. If a passphrase which includes spaces is used, it must be surrounded by quotes to stop the shell parsing it as multiple parameters, e.g. “My Super Secret Passphrase”.
Your mission, should you choose to accept it – and you don’t really have a lot of choice – is to complete the program by filling in the missing code which instantiates objects of the right classes and then calls the appropriate method calls. I created the skeleton by taking the completed, working version, and deleting code while leaving the explanatory comments – but I’ve been reasonably careful to replace multi-line function calls and blocks of code with the same number of blank lines (there’s usually a blank line below the excised code). So if you see a two-line gap, you can reasonably assume that one line of code will provide the missing functionality – and if you think a single line of code will fill a 15-line gap, you should wonder whether you’re missing something.
Along the way, you will need to refer to the online documentation for the Java Cryptography Architecture, which you will find at http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html . The JavaDoc for the various javax.crypto classes are at http://docs.oracle.com/javase/8/docs/api/javax/crypto/package-summary.html while javax.crypto.spec JavaDoc is at http://docs.oracle.com/javase/8/docs/api/javax/crypto/spec/package-summary.html.
You may also need to refer to the Standard Algorithm Names at http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html and the Oracle Providers documentation at http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html .
Anything else can be found under the main Security Documentation at http://docs.oracle.com/javase/8/docs/technotes/guides/security/index.html .
This is a shameless ploy to get you to become at least slightly familiar with the JCA reference documentation – you are quite likely to need it in the real world, as well as for this assignment. However, I will provide some overview guidance in this article.
I’ve also moved the declarations of the required variables and objects to the beginning of the main() method – looking at these will give you some valuable clues.
If you are not a strong Java programmer, you might want to review the skeleton code first, while referring to the notes on Programming Style at the end of this document. However, it should be possible for a non-programmer to work out the required methods and their arguments like algorithm names and transformations from the lectures and the write-up that follows.
The Java Cryptography Architecture
The JCA provides a standard interface which Java programmers can use to both use cryptographic functionality and also implement crypto functionality. Notice the latter point: anybody can develop cryptoprimitives that conform to the JCA and package them, as JAR files, into what are called providers. In this exercise, we will be using one of the default providers from the Oracle Java SE SDK – the SunJCE provider. Others exist and may be preferable if you require some advanced functionality – a good example is the Australian-developed Bouncy Castle package found at https://www.bouncycastle.org/.
Because the JCA is highly generic and algorithm-independent – you can utilise DES, Blowfish or AES with almost-identical code – in many cases you do not directly instantiate a particular class of cipher. Instead, you call a generator or factory method to get an instance of the required cipher or other cryptoprimitive. So the various base classes – Cipher, SecretKeyFactory, KeyPairGenerator, etc. – all provide a static getInstance() method which you should call, usually with the name of the required algorithm as the first parameter.
This technique allows the JCA runtime to search multiple different providers in order to instantiate the required algorithm, rather than tying your code to a specific provider.
Learn how to access Clouddeakin !!
In practice, just the algorithm name alone is insufficient, as discussed in the lectures – we also need to specify what mode the cipher will be used in, as well as a padding mechanism. These options are concatenated with “/” characters as a delimiter, so we arrive at strings like “AES/GCM/NoPadding”, which the JCA documentation calls transformations.
One of the benefits of strongly typed languages like Java is that many errors can be discovered either by the compiler, at compile time, or even by the editor of your IDE. However, in the JCA many different cipher implementations share the same class or interface – and the actual cipher implementation to be used is specified by a string parameter specifying the required transformation.
This means non-existent cipher implementations cannot be discovered at compile time, but only at run time, and so many of the getInstance() calls will need to be surrounded by try/catch blocks. Fortunately, Eclipse will take care of most of that work for you.
The various cryptoprimitives require different sets of their corresponding parameters, and so there are supporting classes such as AlgorithmParameters, KeySpec and its derivatives SecretKeySpec, PBEKeySpec, RSAPrivateKeySpec, etc. that allow the programmer to fully specify how he wants ciphers configured, keys generated, etc.
In general, the various algorithms will provide default values if a parameter is not specified. However, be aware that the various API’s don’t like null pointers. So, for example, if you don’t want to specify a salt value for a KeySpec, you can’t say
salt = null;
but must write:
salt = new byte;
in order to avoid an exception being thrown at run time.
For this exercise, we’ll use the standard SunJCE provider – the original Sun Java Cryptography Engine. All its documentation is in the standard JCA documentation and JavaDoc linked above, and no installation or configuration is required.