nour taher huwio - section 1 - 20200619

The files named "File_Hashing_1.zip" were downloaded from eLearning, and the contents were
extracted and placed on the desktop. The folder containing the three files was opened, and the files
were displayed in a window.
Each of the three images, Image1.jpg, Image2.jpg, and Image3.jpg, was opened, and the pictures
appeared as expected.
The "Details" tab of the Properties window for each file was examined by right-clicking on each file.

HashCalc was successfully downloaded and launched.

By default, HashCalc will calculate MD5, SHA1, RIPEMD160, and CRC32 hashes.
Other options may be selected.
Image1.jpg was dragged into the open HashCalc window, and HashCalc automatically calculated the
hashes using the file as input.

The MD5 hash of Image1.jpg is 71800aa19a191caf813397386f66573b.

The renamed file, "Statue_of_Liberty.jpg" was dragged into the open HashCalc window, and
HashCalc automatically calculated the hashes using the file as input.

The MD5 hash value remains the same because the content of the file has not changed
(71800aa19a191caf813397386f66573b); only the filename has been modified. Hash functions
generate a unique hash value based on the content of the file, not its name. Since the content of
the file remains unchanged, the MD5 hash value will remain the same even after renaming the file.
The hash is calculated using the file’s contents and not using external meta data such as the file’s name
or timestamps.
Image2.jpg and Image3.jpg were dragged into the open HashCalc window, and HashCalc
automatically calculated the hashes for each file.

Based on the hashes provided

The MD5 hash of Image2.jpg matches the MD5 hash of Image1.jpg
(71800aa19a191caf813397386f66573b), indicating that Image2.jpg is an identical match to
Image1.jpg.
The MD5 hash of Image3.jpg (0e5b5b83be6471c7b0bad6a5861e3d53) does not match the MD5
hash of Image1.jpg, indicating that Image3.jpg is not an identical match to Image1.jpg.
Therefore, Image2.jpg is the identical match to Image1.jpg, while Image3.jpg is not.
HashMyFiles was downloaded and installed. The files named "File_Hashing_2.zip" and
"File_Hashing_3.zip" were downloaded from eLearning. Their contents were extracted and placed on
the desktop in their respective folders. HashMyFiles was launched, and a window similar to the one
shown in the instructions appeared. From the main menu, "File" was selected, followed by "Add
Folder." In the "Select Folder" dialog box, "File_Hashing_2" was browsed to and the "OK" button was
clicked. HashMyFiles automatically calculated the hashes of the ten files in "File_Hashing_2" Files
with matching hashes appeared with the same color.
According to the HashMyFiles window, thirty-eight files have been hashed in total.
The files "File-Hashing-9.docx" and "File-Hashing-9 - Copy.docx" do not have the same hashes.
Despite the name "File-Hashing-9 - Copy.docx" suggesting a copy was made of the original, the
contents of the two files do not match.

From the main menu, "Edit" was selected, followed by "Find." In the "Find" dialog box, the hash
value "b638b9a62b9623babaa28af46e0f7409" was entered. The file that matched this hash value
was "File-Hashing-15.docx."
HashCalc was downloaded and installed. FTK Imager was downloaded and installed as well. The
forensic image named drive1.E01 was downloaded from eLearning and saved to the desktop of the
computer. HashCalc was then launched. drive1.E01 was dragged into the open HashCalc window,
and the results of the subsequent hashing were observed.

FTK Imager was launched. From the main menu, "File" was selected, followed by "Add Evidence
Item…" In the "Select Source" dialog box, the radio button next to "Image File" was selected, and
the "Next" button was clicked. drive1.E01 was browsed to on the desktop, selected, and the "Finish"
button was clicked.
From the main menu, "File" was selected again, followed by "Verify Drive/Image…" The results of
drive verification were observed.

The MD5 hash returned from the drive verification is ef7524255c11ac089e532cd3db4d1d46, and
the SHA1 hash is c89f230d0b9a2bb221dc6036b24e8f293dd0c079.

The hashes from HashCalc for the .E01 file encompass the entire file, including both the raw data
from the acquired drive and additional metadata like headers, CRC checks, hashes, and potentially
compression.
Conversely, FTK Imager's drive verification process specifically focuses on hashing the raw data
extracted from the acquired drive, excluding any supplementary metadata.
Consequently, because the hashing process considers different components, the resulting hashes
from HashCalc and FTK Imager are anticipated to diverge.
In cryptography, a collision refers to a situation where two different input values (or messages)
hash to the same output using the same hashing function. In other words, a collision occurs when a
hashing function H produces the same hash value for two distinct inputs x and y.

Collision resistance is a critical property for cryptographic hash functions, as it assures that it is
computationally impractical to find any two different inputs that result in the same output hash.
This property is essential for various security applications, including digital signatures, message
integrity checks, and preventing duplicate entries in data structures like hash tables.
Effective hash functions are designed to minimize the possibility of collisions, thereby ensuring
that the output hash values are as unique as possible for unique inputs. This is crucial for
maintaining the security and reliability of cryptographic systems.

SHA-256 and Its Suitability for Upcoming Years

SHA-256 is part of the SHA-2 (Secure Hash Algorithm 2) family, a set of cryptographic hash
functions published by the National Institute of Standards and Technology (NIST).
Unlike its predecessors such as SHA-1, SHA-256 features a more complex and secure design, which
has rendered it resistant to various forms of cryptographic attacks, including collision attacks,
where two different inputs produce the same hash output.

In the realm of cryptographic security, collision resistance is paramount as it ensures data integrity
by making it computationally infeasible to find two distinct inputs that hash to the same output.
The SHA-256 algorithm specifically is designed to handle 256-bit hashes, which theoretically offers
a vast space of potential outputs (over 10^77 combinations), making it incredibly resistant to
collision attacks due to the sheer computational power required to explore even a fraction of these
possibilities. Recent studies and experiments have shown that while advances in computational
power and attack methodologies (such as the introduction of SAT/SMT-based tools) have led to
minor improvements in collision attack techniques on subsets of SHA-256, these do not compromise
the overall collision resistance of the full 64-step SHA-256 process.
Looking towards the future, SHA-256's design allows it to remain robust against quantum attacks,
which are a concern for many current cryptographic algorithms due to the potential of quantum
computers to solve problems exponentially faster than classical computers. SHA-256's resistance to
Grover's algorithm, a quantum algorithm designed for finding collisions, is noteworthy. While
Grover's algorithm could theoretically speed up brute-force searches, the time complexity of
attacking SHA-256 still remains infeasible with foreseeable quantum technology.

In summary, SHA-256 stands as a robust choice for cryptographic security, even as we step into the
era of quantum computing. Its design principles offer significant resistance to collision and
preimage attacks, ensuring that it will remain suitable for securing digital data and communications
in the upcoming years. Thus, organizations and systems that rely on cryptographic security for data
integrity and authentication should continue to trust and implement SHA-256, given its proven
resilience and the ongoing advancements in maintaining its security strength against emerging
computational capabilities.

Reference:
Li, Y., Liu, F., & Wang, G. (2023). New Records in Collision Attacks on SHA-2. Shanghai Key
Laboratory of Trustworthy Computing, Software Engineering Institute, East China Normal University,
Shanghai, China; Tokyo Institute of Technology, Tokyo, Japan.
https://eprint.iacr.org/2023/285