SOC Blogs
Tutorials
Security Bulletins
About Me
Contact Me!
Tutorials
Tutorials/
🧃
Basic Cryptography Tutorials/
🧃
Symmetric Key Cryptography
Search
🧃

Symmetric Key Cryptography

 

Symmetric Encryption

 
  • Symmetric encryption is used for encrypting data with 1 encryption key.
  • Encryption key is not the same as password, but the key can be derived from a password.
  • Encryption keys do not have any specific structure and can be random arrays of character.
  • Encryption or encryption related alogirthm is also called a cipher.
  • Data to be encrypted is called plaintext.
  • The result of encryption on plaintext is called ciphertext.
  • In order to encrypt plaintext you need to:
    • Chose an encryption algorithm or cipher
    • Generate encryption Key
    • Generate initialization vector or IV
    • Chose cipher operation mode
    • Chose padding type
    • Encrypt plaintext with cipher, key and padding using the cipher operation mode.
 

Overview of Cipher Modes

 

Block Cipher

 
  • Operate on blocks of data
  • A popular cipher is AES or Advanced Encryption Standard
  • Block size of 128 bits
  • Cipher encrypts or decrypts in 128-bit blocks
  • If the plaintext is not a multiple of the block size, then the last block is usually padded up to the block size according to the chosen padding type.
 
 

Stream Ciphers

 
  • Operate on single bytes or even bits of data
  • Do not need padding
  • This makes stream ciphers easier to use
  • Stream cipher generates a so-called pseudorandom cipher digit stream or keystream, based on the encryption key and the IV or nonce (number used once)
  • However researchers believe existing stream ciphers are less secure than block ciphers and it is easier to weaken the security through an implementation mistake.
 

Symmetric Cipher Security

 
  • If an attacker needs to perform 2^256 computational operations to break the cipher then the cipher security is 256 bits.
  • Maximum amount of security bits a cipher can have is the length of the used encryption key.
  • If a cipher uses a 256-bit encryption key its strength is no more than 256 bits.
  • If the key length is 256 bits then there are 2^256 possible encryption keys that can be used with the current cipher.
  • A computational operation does not mean a very basic CPU operation, but a complete attempt at decrypting a small amount of ciphertext.
  • Computational complexity grows exponentially depending on the key length.
  • As of 2021 the recommendation of the NIST is
    • 112 bits of security should be enough until 2030
    • 128 bits of security should be enough until the next breakthrough in technology
 

Reviewing Popular Ciphers

 

AES Cipher

 
  • Most popular modern symmetric cipher
  • Fast and secure
  • Block cipher
  • Rijndael, supports block and key sizes of 128, 192, and 256 bits, but in AES the block size is always 128 bits.
  • The modern x86 and x86_64 CPUs have hardware accelration for AES called Advanced Encryption Standard New Instructions (AES-NI), making AES very fast.
  • AES (Advanced Encryption Standard) is a specification for encrypting electronic data, and it uses a specific encryption algorithm called Rijndael (pronounced "Rhine-dahl") as its core encryption technique.
  • Rijndael was selected as the winner of the NIST competition to become AES in 2001
 

DES and 3DES Ciphers

 
  • Data Encryption Standard (DES) was the predecessor of AES
  • Block cipher with block size of 664 bits and key length of 56 bits
  • 3DES is DES applied three times with two or three different keys
  • It is not recommended to use DES or 3DES for new encryptions
  • DES is rather slow cipher and 3DES is even slower compared to AES.
 

RC4 Cipher

 
  • Old stream cipher that can use key lengths from 40 to 2048 bits
  • Very popular in the past.
  • But currently many flaws were discovered
  • One of the flaws reduces the security of RC4 with 128 bit keys to just 26 bits
  • In 2013,RC4 was used as the main SSL/TLS cipher as all block cipher used in SSL 3.0 was targeted by the infamous Browser Exploit Against SSL/TLS (BEAST) attack, but RC4 being a stream cipher was not affected.
 

ChaCha20 cipher

 
  • Modern Stream Cipher
  • Secure and fast
  • Can be used with 128-bit or 256-bit key
  • OpenSSL supports only the 256-bit key
  • This cipher became famous when Google started to use it in their Chrome browser
  • Then support was also added to OpenSSH
  • Successor of RC4
  • ChaCha20 is faster than AES
  • Encryption of network data streams
  • One disadvantage of ChaCha20 is that it uses a block counter which is only 32-bit.
  • Secure on contiguos plaintexts that do not exceed 256 GB of data.
  • Is enough for network data streams but not enough for large files.
 

Other Ciphers

 
  • Block Ciphers
    • Blowfish → 64 bits
    • CAST5 or CAST-128 → 64 bits (Developed by Canada)
    • GOST5 → 64 bits
    • GOST89 → 64 bits (Russia)
    • IDEA → 64 bits
    • RC2 → 64 bits
    • RC5 → 64 bits
    • ARIA → 128 bit blocks (South Korea)
    • Camellia → 128 bit block
    • SEED → 128 bit block (South Korea)
    • SM4 → 128 bit block (China)
      •  

Block Cipher Modes Of Operation

 
  • Modes of operation or encryption modes
  • Specify how the blocks are chained together
    • ECB or Electronic Code Book
      • Each plaintext block is encrypted into a cipher text block using only encryption key
      • Ciphertext blocks are concatenated
      • Same plaintext always produces the same cipehrtext
      • Security issue since the patterns are preserved and can be reverse-engineered
    • CBC or Cipher Block Chain
      • The ciphertext of the current block depends on the ciphertext of the previous block
      • The 1st block is XOR-ed with an IV or a nonce
      • The rest of the blocks are XOR-ed with the ciphertext of the previous block
      • The IV must be unpredictable for a given message to resist the “Chosen Plaintext Attack”
    • CTR Mode
      • Plaintext is not processed by encryption algorithm.
      • Sequence of counter blocks which consist of 64-bit random nonce and an actual 64 bit counter incrementing for each block is encrypted by the block cipher.
      • The first counter block is not reused for encryption of another plaintext.
      • Then the encrypted counter blocks are XOR-ed with the plaintext blocks. The result is our ciphertext.
      • CTR mode converts a block cipher into a stream cipher where the sequence of encrypted counter blocks is the keystream.
      • The IV used in CTR mode must never be reused with the same encryption key for another message. If you reuse it then the same keystream will be generated for encrypting mutiple messages.
      • Plaintext padding is not required.
      • Different plaintext blocks can be encrypted or decrypted in parallel using pre-calculated keystream
    • GCM Mode
      • Ciphertext is produced in the same way as in CTR Mode
      • Counter blocks are enrypted with block cipher forming the keystream
      • The keystream is then XOR-ed with the plaintext, producing the ciphertext.
      • Difference is GCM not only encrypts the plaintext but also authenticates the ciphertext.
      • Knowledge of the encryption key allows us to verify the integrity of the ciphertext. Basically it can detect unauthorized changes to the the ciphertext if the verification fails.
      • Each ciphertext block is converted into a number and is used in the finite field arithmetic over the Galois field together with an initial block which depends on the encryption key
      • The output of encryption in GCM mode contains IV, ciphertext, authentication tag.
      • Just like CTR, the GCM IV also needs to be unique.
      • Works on 128-bit block sizes and requires 96-bit IV.
      • To respond to this weakness Advanced Encryption Standard in Galois/Counter Mode with a Synthetic Initialization Vector was invented or AES-GCM-SIV
        • It does not take IV as a part of the input data.
        • This algorithm takes a second secret key for authentication
        • The authetnication tag is based on plaintext, additional autheticated data, authentication key. This is called the SIV.
      • This is called Authenticated Encryption or AE.
      • Can combine encrypted and unencrypted data for authentication. It is called Authenticated Encryption with Associated Data or AEAD. GCM is an AEAD.
 

Padding

 
  • In CBC, block ciphers pad up the last block size, which is usually lower than the block size, to the recommended block size.
  • OpenSSL can automatically add the padding and remove the padding during encryption and decryption
  • For symmetric encryption, OpenSSL only supports PKCS7 padding.
  • It pads each remaining bytes with the value ‘N’ or 0x06
  • If the block size also matches the exact block a padding block with value 0x10 is added anyway.
  • Susceptible to padding oracle attacks.
 

Symmetric Encryption Key Others

 
  • Generating an encryption key for symmetric encryption is easy.
  • Generate the needed amount of random bytes from Cryptogaphically Secure Random Number Generator
  • In Linux you can use:
      • xxd -plain -len 32 -cols 32 /dev/random
    • or
      • openssl rand -hex 32
  • Download and install OpenSSL
      • sudo apt install openssl libssl3 libssl-dev libssl-doc
  • The OpenSSL toolkit consists of the following components:
    • Dynamic libraries
    • static libraries
    • C Header Files
    • openssl command line tool
    • documentation
 

How to encrypt and decrypt with AES on the command line

 
  • Let’s generate a sample file to encrypt:
      • seq 1000 > somefile.txt
       
      notion image
       
  • From the above to encrypt using Symmetric Encryption let’s use the followig options
    • Cipher: AES-256
    • Operation mode: CBC (we should have chosen GCM but that mode is not supported by the CLI tool)
  • Let’s generate a 256-bit encryption key
      • openssl rand -hex 32
       
  • We need to generate a 128-bit IV the same length as the block size
      • openssl rand -hex 16
       
      notion image
       
  • Now using the values from above let’s encrypt the file
      • openssl enc -aes-256-cbc -K 6740471107b6238b3a8b173f119117649d51c3410545c3f8466201b00a8c99ac -iv 63e204ba5e1f34b785be5abd218fc216 -e -in plaintext.txt -out plaintext.txt.enc
       
      notion image
       
  • If you try and cat the file you will see that it’s full of random characters.
  • Let’s try and decrypt the file
      • openssl enc -aes-256-cbc -K 6740471107b6238b3a8b173f119117649d51c3410545c3f8466201b00a8c99ac -iv 63e204ba5e1f34b785be5abd218fc216 -d -in plaintext.txt.enc -out plaintext.txt.dec
diff plaintext.txt plaintext.txt.dec
       
  • We can check the checksum also of both the files to verify
      • shasum -a 256 plaintext.txt

shasum -a 256 plaintext.txt.dec
       
      notion image
 
 

What happens if we try and decrypt a file using wrong key

 
Let’s re-run the same decrypt command but this time we use a different key which is a wrong one
openssl enc -aes-256-cbc -K 6744471107b6238b3a8b173f119117649d51c3410545c3f8466201b00a8c99ac -iv 63e204ba5e1f34b785be5abd218fc216 -d -in plaintext.txt.enc -out plaintext.txt.dec
 
notion image
 
Decryption here is just a sequence of arithmetical and logical operations on a block of 16 bytes. It is the standard padding here that helped.
 
The decryption of the last block resulted in a block of garbage data, which did not have the right padding at the end and openssl detected that.
 
So in a decryption process untill the last block it is impossible to detect failure.
 

What happens if we used cipher operation mode that did not require padding - like CTR?

 
openssl enc -aes-256-ctr -K 6744471107b6238b3a8b173f119117649d51c3410545c3f8466201b00a8c99ac -iv 63e204ba5e1f34b785be5abd218fc216 -d -in plaintext.txt.enc -out plaintext.txt.dec

ls -l
   rw-r--r--   1   boredtoolbox   staff      3 KiB   Sun Feb 11 22:18:36 2024    plaintext.txt
   rw-r--r--   1   boredtoolbox   staff      3 KiB   Sun Feb 11 22:48:36 2024    plaintext.txt.dec
   rw-r--r--   1   boredtoolbox   staff      3 KiB   Sun Feb 11 22:20:31 2024    plaintext.txt.enc

diff plaintext.txt plaintext.txt.dec
Binary files plaintext.txt and plaintext.txt.dec differ

shasum -a 256 plaintext.txt.dec
b67eda76485fe249e4d5cce4226b62bcee7224a3d35931a652be94c889bb2a4d  plaintext.txt.dec

shasum -a 256 plaintext.txt
67d4ff71d43921d5739f387da09746f405e425b07d727e4c69d029461d1f051f  plaintext.txt
 
There was no error even though we tried to decrypt in the wrong key and in the wrong mode. The checksums of the decrypted and the original file are clearly different. So what happened?
 
We were decrypting in CTR mode. Thus all the wrongly decrypted data was considered plaintext without padding. The padding was neither checked nor was it removed.
 
Thus we can see that it is quite useful to have some checksum or message digest in order to check the decryption result.
 

Summary

 
- openssl rand -hex 32 > enc.key
- openssl rand -hex 16 > iv.key
- openssl enc -aes-256-cbc -kfile enc.key -iv $(cat iv.key) -e -in plaintext.txt -out plaintext.txt.enc
- openssl enc -aes-256-cbc -kfile enc.key -iv $(cat iv.key) -d -in plaintext.txt.enc -out plaintext.txt.dec