linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-developers] AES ICM encryption in SRTP


From: Hilman Fitriana
Subject: [Linphone-developers] AES ICM encryption in SRTP
Date: Sun, 5 Jul 2020 18:41:24 +0700

Hello,

I tried to understand how the implementation of srtp on the linphone application. When I activate the srtp feature on the phone, the digital data communication will be secured using the AES-ICM encryption method. But I found something interesting in its implementation.

The encryption process in the AES-ICM method works with xor operations between keystream suffix and RTP packet payload (plaintext) to produce ciphertext. The encryption key is used in an aes operation to generate a suffix keystream. This ciphertext will then be sent from the sender to the receiver.

In the implementation of SRTP, I display the plaintext, key and ciphertext used or generated by the sender and receiver. I found the difference between the ciphertext and key for each packet in the sender and receiver. When a plaintext is encrypted using a specific key and produces a ciphertext in the sender, at the receiver, the ciphertext that is received and the key that is used has a difference. However, the strange thing that I found was that the results of the decryption of the plaintext on the receiver are the same plaintext as what is encrypted in the sender. And the voice that was communicated arrived, can anyone explain this why?
Here are, the code I add to show the plaintext, key and ciphertext and also the log in sender and receiver.

  1. Code to display text : https://pastelink.net/1re6m

  2. Log endpoint 1 : https://pastelink.net/1re93

  3. Log endpoint 2 : https://pastelink.net/1re9c

Then, I tried to deactivate the encryption feature by using the srtp_cipher_encrypt code in the srtp_protect_mki and srtp_cipher_decrypt modules in the srtp_unprotect_mki module. Isn't that as if it didn't encrypt the payload like the Null Cipher is implemented? However, the same ones found are ciphertext and plaintext that have nothing in common with the sender and receiver as well as the sound on the speakers that contain noise without being able to identify what is being sent. Can anyone explain this too?

Best Regard,
Hilman


reply via email to

[Prev in Thread] Current Thread [Next in Thread]