6 Commits

Author SHA1 Message Date
Leo
a2363e3f51 feat: ex a2d
All checks were successful
zip and release / build-and-release (push) Successful in 5s
2026-04-23 13:13:19 +02:00
Leo
4464bf55a9 feat: use cksum for sha2+3 hash 2026-04-23 12:19:26 +02:00
Leo
7da7d4e51d feat: ex 2c 2026-04-23 12:10:55 +02:00
Viktoria Konschuh
6051b5f720 sha2 2026-04-22 16:39:35 +02:00
Viktoria Konschuh
b8d311adf5 Edit plaintext.txt 2026-04-22 14:08:39 +00:00
Julian Golenhofen
1eeefff2c3 task 1 2026-04-22 13:52:43 +00:00
9 changed files with 76 additions and 1 deletions

2
.gitignore vendored
View File

@@ -1 +1,3 @@
*.pdf *.pdf
sheet01/a2/Hash.java
*.class

View File

@@ -0,0 +1,31 @@
## java.util.Random
a) Numbers are generated using a linear congruential generator. They are pseudorandom and the algorithm accepts a 48-bit seed.
b) `java.util.Random` produces uniformly distributed pseudorandom numbers.
c) No, in the documentation `SecureRandom` is recommended as a good alternative for cryptographic use-cases.
## java.lang.Math.random()
java.lang.Math.random() is a wrapper for java.util.Random (therefore same as above).
## java.security.SecureRandom
a) A unpredictable source of randomness should be used, but the algorithm in use can vary since `SecureRandom.getInstance("algorithm")` exists. Multiple ones are available.
b) The distribution of numbers is completely random and unpredictable.
c) Yes, hence the name, `SecureRandom`.
## /dev/random
a) The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. It keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool, random numbers are created.
b) The distribution of numbers is completely random and unpredictable.
c) Yes, all use cases are fine.
## /dev/urandom
Preferred to random except for applications that require randomness at early boot time since it is not available there. The rest is the same as for `dev/random`.

1
sheet01/a2/b-sha2.txt Normal file
View File

@@ -0,0 +1 @@
SHA256 (plaintext.txt) = 95f3afed37754b0aaec0c57bea62389621f6ce2a299f64b849acd43651e3668c

1
sheet01/a2/b-sha3.txt Normal file
View File

@@ -0,0 +1 @@
SHA3-256 (plaintext.txt) = 8cdcfd9d0414adbba1bb146c214e181d7e5d7c8edde90b79dcb27df005fcc298

View File

@@ -0,0 +1,4 @@
cksum -a sha2 --length 256 plaintext.txt > b-sha2.txt
reads the plaintext file and calculates a unique hash string using the SHA2-256 cryptographic algorithm and writes it into b-sha2.txt
cksum -a sha3 --length 256 plaintext.txt > b-sha3.txt
reads the plaintext file and calculates a unique hash string using the SHA3-256 cryptographic algorithm and writes it into b-sha3.txt

1
sheet01/a2/c-hash.txt Normal file
View File

@@ -0,0 +1 @@
03087115

View File

@@ -0,0 +1,3 @@
javac Hash.java (Compiles the java class)
java Hash plaintext.txt (runs the custom Hash function on the text file)
Output: 03087115

View File

@@ -0,0 +1,29 @@
The custom hash is adding the unicode values of each character, the amount of rows and the amount of characters each multiplied with a hex value.
This leads to it giving the same output when switching around rows, or even putting all characters into one line and adding the required amount of empty lines behind that.
"""
LJVeuiolknitaaornrdia
"""
is producing the same hash as
"""
Leonard
Viktoria
Julian
"""
and the same as
"""
Julian
Leonard
Viktoria
"""
It has a good enough "first pre-image resistance" since it is not really possible to find the correct characters in the same order from the hash value that give the same original file
The "second pre-image resistance" is weak since you can easily calculate a different file which gives the same output.
It has no collision resistance since you can just switch around characters and get the same hash.

View File

@@ -0,0 +1,3 @@
Julian
Leonard
Viktoria