# Exercise set 5
by Samuel Fountain fount032, Griffin Higley, Nat Rose

## 1) Broken RNGs

### a)
To generate the symmetric key K, the attacker would have to have the exect same inputs as the user. Lets evaluate the inputs.

| Input Value | What We Know | Possible Values |
|------------------------------|-----------------------------------|-----------------|
| Current time in microseconds | millisecond accuracy current time | 1000 |
| Browser PID | It is a 16-bit number | 2^16 |
| Parent PID | Parent PID is 1 | 1 |

So there are 65536000 or 6.5536E+7 different possible input value combinations for the encryption key resulting in the same number of possible symmetric keys.

For an on path adversary there is only 1 semeteric key exchanged (K) for a captured key exchange.

An attacker could test a possible key by encrypting their generated key (K') with the servers public RSA key and checking to see if the ciphertext matches ciphertext of the encrypted key K that the client sent to the server. If the ciphertexts match then K' = K and the adversary knows what the symmetric encryption key is.

Our VM can perforem 102638 1024-bit public key operations per second. At this rate it would take an attacker 638.52 seconds (less than 11 minutes)to check all possible symmetric keys.
### b)
A 15-bit value can have 2^16 or 65536 different possible values. Therefore, There are 65536 different possible public keys a machine running that build of sshd could have. Using `time openssl dhparam 1024` We find out that generating a 1024 bit openssl public key would take 2.149 seconds. So it would have taken 1173.64 or just over 19 and a half hours to generate all possible public keys for this build of sshd.
## 2) Mal-in-the-Middle attacks I : Replay

A reply attack on OCSP that would allow a *Mal-in-the-Middle* to convince a client that a certificate is valid, even after it has been revoked would work with the following flow.

First the *client* sends the server a query, **_Hash_(CertID)** to *Mal*

Then *Mal* sends **_Hash_(CertID)** on to the *server*

The *server* responds to *Mal* with **_Sigs_("valid", _Hash_(CertID))**

*Mal* then saves the value **_Sigs_("valid", _Hash_(CertID))** for later use and sends **_Sigs_("valid", _Hash_(CertID))** to the *client*

Some time goes by, during which *server* must revoke their certificate for some reason.

The *client* then sends *Mal* **_Hash_(CertID)** if *Mal* wants to perform a replay attack and make *client* belive that the certificate is still valaid all *Mal* has to do is send the value it has stored **_Sigs_("valid", _Hash_(CertID))** to *client* and *client* will belive the revoked certificate is actually valid.

## 3) Mal-in-the-Middle attacks II: Downgrade

First the *client* will send a hello message to *Mal*

Then *Mal* will send the hello message on to the *mail server*

The *mail server* will respond to *Mal* with `250 STARTTLS`

*Mal* will than take this message and strip the end off so the message now read `250` and will forword that onto the *client*

After this the *client* will just continue to use unencrypted SMTP commands because it thinks that the *server* does not support TLS and the *server* will use unecrypted SMTP commands because it thinks that the *client* does not support TLS.

## 4) Crypto protocols
### a)

| URL | Cipher |
| -------- | -------- |
| www.umn.edu:443 | ECDHE-RSA-AES256-GCM-SHA384 |
| www.google.com:443 | TLS_AES_256_GCM_SHA384 |

### b)
#### https://www.umn.edu

**Public Key :** RSA 2048-bit Public Key

**Expiration Date :** 10/27/2021, 11:59:59 PM CUT

**Other Domains**
- ur.umn.edu
- *.pharmacy.umn.edu
- *.prd.umn.edu
- *.vetmed.umn.edu
- advocate.umn.edu
- advocates.umn.edu
- amplification.umn.edu
- brief.umn.edu
- campus-climate.umn.edu
- campusclimate.umn.edu
- d2d-2017-campaign.umn.edu
- directory.umn.edu
- discover-archive.umn.edu
- discover.umn.edu
- driven-to-discover.umn.edu
- driventodiscover.umn.edu
- drugdesign.umn.edu
- government-relations.umn.edu
- governmentrelations.umn.edu
- hub.ahc.umn.edu
- legislative-action.umn.edu
- legislativeaction.umn.edu
- news.umn.edu
- photo-video.umn.edu
- photo.umn.edu
- president.umn.edu
- study-away.umn.edu
- studyaway.umn.edu
- twin-cities.umn.edu
- twincities.umn.edu
- university-district.umn.edu
- university-relations.umn.edu
- universityrelations.umn.edu
- www.advocate.umn.edu
- www.advocates.umn.edu
- www.brief.umn.edu
- www.cahfs.umn.edu
- www.csh.umn.edu
- www.dentalclinics.umn.edu
- www.dentistry.umn.edu
- www.directory.umn.edu
- www.discover.umn.edu
- www.driven-to-discover.umn.edu
- www.equine.umn.edu
- www.government-relations.umn.edu
- www.governmentrelations.umn.edu
- www.itdd.umn.edu
- www.legislative-action.umn.edu
- www.legislativeaction.umn.edu
- www.news.umn.edu
- www.nursing.umn.edu
- www.photo-video.umn.edu
- www.photo.umn.edu
- www.president.umn.edu
- www.raptor.umn.edu
- www.study-away.umn.edu
- www.studyaway.umn.edu
- www.tc.umn.edu
- www.twin-cities.umn.edu
- www.twincities.umn.edu
- www.university-district.umn.edu
- www.university-relations.umn.edu
- www.universityrelations.umn.edu
- www.ur.umn.edu
- www.vdl.umn.edu
- www.vmc.umn.edu

#### https://www.google.com

**Public Key :** Elliptic Curve 256 P-256 Curve

**Expiration Date :** 6/24/2020, 12:58:56 PM CUT

**Other Domains**
- www.google.com

### c)

| Server | Public Key |
| -------- | -------- |
| apollo.cselabs.umn.edu | RSA |
| csel-kh1250-13.cselabs.umn.edu | RSA |
| github.umn.edu | RSA and ecdsa-sha2-nistp256|