I need help completing my assignment for COMP2300: Applied Cryptography. There are two parts that need to be completed. Part 1 is a little exercise based on attacking a hash function. The expert will...

I need help completing my assignment for COMP2300: Applied Cryptography. There are two parts that need to be completed. Part 1 is a little exercise based on attacking a hash function. The expert will need to create a class called JHTest, then paste the following code into it and answer two questions related to part 1. Part 2 is calculating a digest over a file. Part 2 requires completing the program by filling the missing code which initiates objects of the right classes and then calls the appropriate method calls. The expert will then need to answer question 3, 4, and 5 related to part 2. All the information related to the assignment is inCOMP2300_SHFYR_2021_ALL_U_ Assignment 1 - File Digests with the Java Cryptography Architecture. The questions for both part 1 and 2 need to be answered in Assignment1.txt. FileProperty needs to be imported into Eclipse.


import java.io.BufferedInputStream; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.security.NoSuchAlgorithmException; /** * Program to calculate a security property of a file, * consisting of SHA3-256 (or other) digest over the file, * prefixed with a shared secret */ /** * @author * */ public class FileProperty { private static final String progName = "FileProperty";// Name of the program private static final int bufSize = 512;// Almost any sensible value will work here /** * @param args */ public static void main(String[] args) { BufferedInputStream in = null;// A buffered input stream to read from byte[] inputBuffer = new byte[bufSize];// A buffer for the input read from the file int bytesRead = 0;// Number of bytes read into the input file buffer byte[] messageDigest = null;// A variable for the actual digest value, as an array of bytes // First, check the user has provided all the required arguments, and if they haven't, tell them then exit if(args.length != 2) { printUsageMessage(); System.exit(1); } // Open the input file try { in = new BufferedInputStream(new FileInputStream(args[1])); } catch (FileNotFoundException e) { printErrorMessage("Unable to open input file: " + args[1], null); System.exit(1); } // Insert the correct class name for the required cryptoprimitive (1 mark, 1 word) < class="" name="" goes="" here="">> digestCryptoprimitive = null; // Now, instantiate the required cryptoprimitive (2 marks, 5 or 6 lines) // Now, start the hash calculation with the shared secret (1 mark, 1 line) // "Prime the pump" - we've got to read something before we can digest it // and not do anything if we read nothing. try { bytesRead = in.read(inputBuffer); } catch (IOException e) { printErrorMessage("Error reading input file " + args[1],e); System.exit(1); } // As long as we've read something, loop around updating the digest value // bytesRead will be zero if nothing was read, or -1 on EOF - treat them both the same while (bytesRead > 0) { // Update the digest with the bytes that were read (2 marks, 1 line) // And read in the next block of the file try { bytesRead = in.read(inputBuffer); } catch (IOException e) { printErrorMessage("Error reading input file " + args[1],e); System.exit(1); } } // Get the final digest value (1 mark, complete 1 line) messageDigest = // And print the digest value as a long hex string (1 mark, 1 line) } /** * Print an error message on stderr, optionally picking up additional detail from * a passed exception * @param errMsg * @param e */ private static void printErrorMessage(String errMsg, Exception e) { System.err.println(errMsg); if (e != null) System.err.println(e.getMessage()); } /** * Print a usage message */ private static void printUsageMessage() { System.out.println(progName + " $Revision: 1.0 $: Usage: " + progName + " "); } final protected static char[] hexArray = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'}; /** * Convert an array of bytes to a hexadecimal string representation * Start with the top byte and work down in memory, i.e. Internet big-endian representation, * as used in block symmetric cryptography * @param bytes the array to be converted * @return a string of hex digits */ public static String byteArrayToHexStr(byte[] bytes) { char[] hexChars = new char[bytes.length*2]; int v; for(int j=bytes.length - 1 , cp = (bytes.length - 1) * 2; j >= 0; j--, cp -= 2) { v = bytes[j] & 0xFF; hexChars[cp] = hexArray[v>>>4];// Most Significant (Upper) Nybble hexChars[cp + 1] = hexArray[v & 0x0F];// Least Significant (Lower) Nybble } return new String(hexChars); } } /* Template for answer file Assignment1.txt. Upload this, along with your completed Digest.java file. */ Question 1: Question 2: Question 3: Question 4: Question 5: Commercial National Security Algorithm Suite and Quantum Computing FAQ 2 General Q: To whom is the CNSS Advisory Memorandum 02-15 addressed? A: NSA's announcement of changes from Suite B cryptography to the Commercial National Security Algorithm Suite are for organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS. NSA is operating under authority it has for setting policy and issuing guidance for NSS—codified in National Security Directive 42 (NSD-42), the Federal Information Security Management Act of 2002 (FISMA) and Department of Defense Instruction 8523.01. To reach the broadest set of NSS operators, customers, and vendors, and to facilitate NSA’s Commercial Solutions for Classified (CSfC) effort, this information has been posted on the nsa.gov website. The NSA announcement is designed to provide sufficient notice to NSS developers and operators to plan and budget for new cryptography as they design their systems. Cryptographic upgrades to NSS often require several years of planning. NSA wants to make sure all NSS owners and developers understand the long term need to transition, and include this in their budget, maintenance, and logistics plans. Q: What is the Commercial National Security Algorithm Suite? A: The Commercial National Security Algorithm Suite is the suite of algorithms identified in CNSS Advisory Memorandum 02-15 for protecting NSS up to and including TOP SECRET classification. This suite of algorithms will be incorporated in a new version of the National Information Assurance Policy on the Use of Public Standards for the Secure Sharing of Information Among National Security Systems (CNSSP-15 dated October 2012). The Advisory Memorandum and Policy define the set of public cryptographic standards that may be used to protect NSS until acceptable public standards for quantum resistant cryptography exist and are approved for use in NSS by the Committee for National Security Systems (CNSS). The Commercial National Security Algorithm Suite includes: Algorithm Usage RSA 3072-bit or larger Key Establishment, Digital Signature Diffie-Hellman (DH) 3072-bit or larger Key Establishment ECDH with NIST P-384 Key Establishment ECDSA with NIST P-384 Digital Signature SHA-384 Integrity AES-256 Confidentiality Commercial National Security Algorithm Suite and Quantum Computing FAQ 3 NSA prefers the use of ECDH with P-384 and 3072-bit DH for key establishment. CNSS Advisory Memo implementation Q: Doesn’t CNSSP-15 require all commercial NSS acquisitions to incorporate Suite B elliptic curve algorithms by October 2015? A: Prior to the release of CNSS Advisory Memorandum 02-15 in August 2015 it did. That was an important consideration in the timing of the memorandum. CNSS Advisory Memorandum 02-15 removes that requirement. CNSSP-15 is being updated and will take some time to publish. In the interim, CNSS Advisory Memorandum 02-15 describes the most up-to-date algorithm guidance. See the advisories tab at www.cnss.gov. Q: I have already complied with the current CNSSP-15 requirements incorporating Suite B into my NSS commercial product/solution. Do I need to update any of the algorithms being used? A: If you have already implemented Suite B algorithms using the larger (for TOP SECRET) key sizes, you should continue to use those algorithms and key sizes through this upcoming transition period. In many products changing to a larger key size can be done via a configuration change. Implementations using only the algorithms previously approved for SECRET and below in Suite B should not be used in NSS. In more precise terms this means that NSS should no longer use • ECDH and ECDSA with NIST P-256 • SHA-256 • AES-128 • RSA with 2048-bit keys • Diffie-Hellman with 2048-bit keys CNSS Advisory Memorandum 02-15 makes one exception allowing the use of RSA with 2048- bit keys for public key infrastructures Q: What systems are affected by the new CNSS advisory memorandum? A: CNSS Advisory Memorandum 02-15 applies to all NSS—classified and unclassified, as defined in NSD-42 and FISMA. Users are expected to migrate to comply with the new requirements; however it is understood that not all applications can change easily or immediately. For specific program questions, engage with NSA for further guidance. Q: Given the range of algorithm options and sizes to choose from, which is best? A: CNSS Advisory Memorandum 02-15 alerts NSS developers and operators of the need to transition to quantum resistant algorithms in the future and permits greater flexibility in algorithm choice today than was allowed under the existing CNSSP-15. This flexibility avoids making systems that do not already comply with CNSSP-15 first do an upgrade to comply with http://www.cnss.gov/ Commercial National Security Algorithm Suite and Quantum Computing FAQ 4 CNSSP-15 and then perform a second upgrade to comply with the quantum resistant CNSSP-15 to be issued in the future. Within this framework, developers, operators and users should choose the most cost effective path to come into compliance with CNSS Advisory Memorandum 02-15. NSS developers, operators or users who need additional guidance should contact NSA. Q: Which specific algorithm parameters should NSS use? A: NSS users should select groups based upon well established and validated parameter sets that comply with the minimum required sizes. Some specific examples include: • Elliptic Curves are currently restricted to the NIST P-384 group only for both ECDH and ECDSA, in accordance with existing NIST and NIAP standards. • RSA moduli should have a minimum size of 3072 bits (other than the noted PKI exception), and keys should be generated in accordance with all relevant NIST standards. • For Diffie-Hellman use a Diffie-Hellman prime modulus of at least 3072 bits as specified in IETF RFC 3526 (Groups 15-18). Note: A new set of Diffie-Hellman primes is being considered for use in a new Transport Layer Security specification (TLS 1.3) —these may also be acceptable. Q: I have already provisioned RSA 4096 certificates on a number of devices used in NSS. Should I move to RSA 3072 certificates? A: Not necessarily—RSA with 4096 modulus size exceeds the 3072 minimum modulus size and is acceptable for use. Interoperability