Task 1:

1.1)

Here the Student number is: 250922600

[2, 5, 0, 9, 2, 2, 6, 0, 0]

So the ciphertext is:

[81, 93, 248, 191, 81, 81, 213, 248, 248]

1.2)

The ciphertext is:

[15, 246, 105, 24, 15, 15, 144, 105, 105]

1.3)

M = {strings of bytes}

Gen: choose uniform byte k ∈ K = {0,. . . ,255}

Enck (m1 . . . mt): output c1 . . . ct

where ci := mi ⊕ k

Deck (c1 . . . ct): output m1 . . . mt

where mi := ci ⊕ k

Task 2:
2.1)

The plaintext is as follow:

ellusion
2.2)

The algorithm which will be used to recover the plain text from the cipher text is as
follows :-

As we know that 'a' : 97 , 'b' : 98 and so on... so we will be given an array of cipher text
and we will run a loop for the cipher text and create a map where we will store all the
values corresponding to 97,98... and so on....

Hence, for the given cipher text we will print the plain text as expected !!

Task 3:
A block cipher like AES is deterministic: for a similar key and a similar information, you
get a similar yield. Since genuine information will in general show repetition, this makes
ECB, the most essential cipher mode, very feeble. CBC attempts to keep away from
that issue by "randomizing" the info blocks, through a XOR with the past scrambled
block: the thought is that the yield of a block cipher should look "adequately arbitrary".
(Overall, around 264 blocks, which is 256 exabytes, also known as "a horrendous part
of information"; this won't occur regularly). Since the primary block has no past block,
we need a "fake past block" and that is the IV. Consequently, the IV ought to be
"arbitrary looking".

So the initial sixteen bytes of the two scrambled messages will be indistinguishable. By
recognizing that fairness, the aggressor will then, at that point, find precisely what
pieces contrast in the principal byte of every secret key. By noticing numerous
progressive messages, the assailant might amass a considerable amount of such
conditions on the obscure information. This is actually the sort of spillage that great
encryption ought to stay away from.

The circumstance is aggravated much within the sight of picked plaintext attacks: these
are attacks where the scalawag will pick the piece of the plaintext. In the model
portrayed above, assume that the assailant is one of the clients, and his secret key is in
the main message. Hence, the aggressor realizes that his secret phrase starts with an
'm'; by noticing the encryption of the progressive messages, he then, at that point,
deduces that the secret phrase in the fifth message starts with 'a'. Besides, the assailant
might change his secret key and have another go, getting data on different passwords,
etc.
The as of late promoted BEAST assault expands on a CPA, in a more practical situation
including a Web program, an HTTPS association, and a "secure" Paypal cookie. The
foundation of the assault is that information in an SSL association is broken into
"records", each record being scrambled in CBC mode, and the last block of a record is
utilized as IV for the following. The assailant then, at that point, constrains his very own
few information into the association, notices the primary record, and registers from that
the information he then, at that point, adds (which will be encoded as the subsequent
record), so the main block of that information XORed with the IV yields an anticipated
worth. The subtleties are many-sided, however end up with uncovering the safe cookie.
For the assault to work, all the aggressor needs is an anticipated IV, which he gets by
noticing records (TLS 1.1 fixes that by adding per-record irregular IV).

To summarize, the BEAST assault exhibits that CBC with an IV that can be anticipated
by an aggressor who can do picked plaintext attacks is powerless. A +1 strategy for IV
administration prompts IV that can be effortlessly anticipated. In this manner.

One will take note of that while CBC requires irregular, uniform, unusual IV, not all block
cipher methods of tasks are simply fussy. Many cool more current modes, particularly
those which join encryption and respectability check, can live with non-rehashing IV
regardless of whether the IV qualities are absolutely non-irregular (for example EAX or
GCM); as far as they might be concerned, a +1 on IV is totally fine. In certain
conventions, this considers a verifiable IV (an arrangement number, for progressive
messages sent over a wire) which might save a touch of transfer speed.

Task 4:
4.1)

These tests prove the files are different.

4.2)

As the MD5 and SHA1 hash are performed on the two files it is obvious that this two files will ve
hased with different hash function and the end result wont give same answer.