This page con­tains var­i­ous unstruc­tured notes about cryp­to relat­ed things.

General notes

• If you find some­where that some­thing should be ran­dom, but it isn’t, this is already an impor­tant finding.

Stream Ciphers

• A stream cipher encrypts a clear­t­ext bit for bit or char­ac­ter for char­ac­ter (nor­mal­ly via XOR) with a secret key. It pro­duces a key stream which it XORs with the clear­t­ext stream to cre­ate the cipher stream.
• The secret lies in the secret key (= called IV ini­tial­iza­tion vec­tor) and the algorithm.
• The IV must not used twice or an attack­er can retrieve the clear­t­ext via XOR­ing both cap­tured ciphertexts.
• The algo­rithm must have a large peri­od and must nev­er repeat the same encryp­tion pattern.
• Before an algo­rithm pro­duces the same key stream again, the key/IV must be changed (= rotated).
• A longer IV pro­vides more infor­ma­tion for the algo­rithm so that the peri­od can be longer before key rota­tion is needed.
• A short­er IV pro­vides less infor­ma­tion for the algo­rithm so that the peri­od must be short­er before key rota­tion is needed.

Block Ciphers

• A block cipher encrypts a fixed-length clear­t­ext block with a key of the same length as the block into a cipher­text block.
• If a clear­t­ext is short­er as the block­size, padding has to been used.
• If a clear­t­ext is longer as the block­size, the clear­t­ext has to been split into mul­ti­ple blocks.
• A block cipher mode deter­mines how a clear­t­ext block is trans­formed into a cipher­text block. The main ones are:
  • ECB Elec­tron­ic Code­book Mode: Each block is encrypt­ed with the same key.
    • It often pro­duces pat­terns. A clear­t­ext block is always encrypt­ed to the same cipher­text if their lenghts match.
    • Look for repeat­able parts in the ciphertext. 
  • CBC Cipher Block Chain­ing Mode: Like ECB, but before each round, the key block is XOR’d with a chang­ing val­ue. There­fore the key block looks dif­fer­ent at each round and thus the same clear­t­ext won’t pro­duce the same ciphertext.
    • For the first round, anoth­er ini­tial val­ue is needed.
    • From the sec­ond round on, usu­al­ly a part of the pre­vi­ous­ly gen­er­at­ed cipher­text block is used.
    • This means also that if one block is cor­rupt­ed, the clear­t­ext from this block on is lost.
    • This method works only sequentially.
  • CTR Counter Mode: Like ECB, but the chang­ing val­ue before each round is a val­ue from a seri­al­ized sequence which can be pre­dict­ed. Nor­mal­ly increas­ing numbers.

Heuristics to determine the crypto algorithm

Look to the size of mul­ti­ple encrypt­ed files.

• Is the size always even­ly divis­i­ble by 8?
  • Maybe a stream cipher, RC4
• Is the size always even­ly divis­i­ble by 16?
  • Maybe AES
• Is the size some­times divis­i­ble by 16, some­times by 8?
  • Maybe DES/3DES

Checking entropy

Check the entropy of the data: (CyberChef, pcaphistogram.py)

• High­er entropy: Prob­a­bly encrypted.
• Low­er entropy: Prob­a­bly (part­ly) compressed

Use tcpick -r t.pcap -wR to extract the raw data with­out TCP/IP head­ers. Then use ent to cal­cu­late the entropy of the TCP streams.

Attacking CBC Cipher Block Chaining Mode

Sce­nario:

• You found out that a CBC-based ID is used some­where and stores come con­tent you want to change. For exam­ple, a web appli­ca­tion stores the user id in a cookie.
• The cook­ie has the fol­low­ing val­ue: U2FsdGVkX19TNGlhPemU/Ob/PhaDjIBTnsIkwsNfeGg=. This rep­re­sents your UID 1042.
• You want to change this val­ue to UID 1000 to be rec­og­nized as admin­is­tra­tor by the web application.

Preper­a­tion: Let’s cre­ate a cipher­text and encrypt and decrypt it. Note that we use a ran­dom pass­word here which does­n’t mat­ter because we are going to change only the encod­ed UID val­ue and the serv­er will decrypt out pro­vid­ed val­ues with­out the need for us to know the server’s password.

// Create the file with the value and encrypt and decrypt.
$ echo "1042" > uid.cleartext
$ openssl enc -aes-128-cbc -in uid.cleartext -out uid.ciphertext // Typed "password" at the password prompt.
$ openssl enc -aes-128-cbc -d -in uid.ciphertext -pass pass:password
1042

// Convert binary file into hex string.
$ cat uid.ciphertext | xxd --plain -c 100 > uid.hexstring

// Convert from hex string into a binary file again.
$ cat uid.hexstring | xxd -r -p > uid_new.ciphertext

// Check that both files are identical.
$ md5sum uid_new.ciphertext  uid.ciphertext
c95fbe7ded09bab641141296ddb6125d  uid_new.ciphertext
c95fbe7ded09bab641141296ddb6125d  uid.ciphertext

// This leads us to the following one liner which we can play:
$ echo 53616c7465645f5f533469613de994fce6ff3e16838c80539ec224c2c35f7868 | xxd -r -p | openssl enc -aes-128-cbc -d -in -  -pass pass:password
1042

Hash length extension attack

Sce­nario:

• A web­serv­er offers a file to down­load but also requires a hash to “prove” that you are allowed to down­load this file. You know one file and hash: /download/?file=public.pdf&h=905d6439e669681be03727687de68d47
• You want to down­load arbi­trary files now: For exam­ple: /download/?file=/etc/passwd&h=???

To do this, we are using hash_extender. Its readme con­tains a good expla­na­tion how it works. Note that it only works if the serv­er prepends the secret.

1. Cre­ate a new sig­na­ture and URL string with some­thing like:
   ./hash_extender -d public.pdf -s 676dc17ec36bc6f200595e4a5ad0a9b2cee0c8b3 -a ../secret.pdf --format sha1 -l 9 --out-data-format html