AES

JSON Reference

AES-Encryption-Server

The server role of an AES encrypted connection. This is typically used on the remote side of a tunnel configuration. This is recommended, because the server role generates the encryption initialisation vector (IV), and password derivation salt. The privileged side, the remote host should have control over such a privileged role where security strength is determined by random generation and no reuse of this kind of data.

There is a single inline string value parameter:

  • Password key string - is a simple string that contains the text of the shared password used at both sides of the duct.

Example

"AES-Encryption-Server": "TERybtzdKyXE8sYn",

Properties

  • Activation Phase = Top Down

  • Type = Encapsulating

  • Stream Interaction = ongoing

  • JSON Value Type = inline string

  • Initiator = No

AES-Encryption-Client

The client role of an AES encryption connection. This is typically used on the support side of a tunnel configuration.

There is a single inline string value parameter:

  • Password key string - is a simple string that contains the text of the shared password used at both sides of the duct.

Example

"AES-Encryption-Client": "TERybtzdKyXE8sYn",

Properties

  • Activation Phase = Bottom Up

  • Type = Encapsulating

  • Stream Interaction = Ongoing

  • JSON Value Type = inline string

  • Initiator = No

Not secure enough on its own

This method of encryption is not security enough to use on its own. TLS is the gold standard for comprehensive implementation of stream encryption protocols. See TLS section "The importance of TLS" for more details. In production, you should only use an AES as well as TLS. TLS is encrypting AES which is encrypting plain text.

Implementation details

System.Security.Cryptography.AESManaged is used to encrypt blocks in CBC mode. see https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.aesmanaged?view=netframework-4.5.2

Initialisation

The server role generates salt per connection using RNGCryptoServiceProvider; The key is derived the password string using System.Security.Cryptography.Rfc2898DeriveBytes; The IV is generated by the server and shared with the client.

Framing

Encryption is performed on a frame that is composed of the length of the message data, the message data, and then padding with zeros.

Encrypted data is received a block at a time. When decrypted, the first block starts with the length of the full post-decrypted message. Decryption continues until that amount of message has been decrypted, and any padding is discarded. Then it is known that the next frame will be received.

Future improvements

Although TLS is highly recommended, we aim high for the security of the Dull AES duct type. We plan to shift toward Authentication-Encryption (AE) GCM mode for security and performance. GCM eliminates the need for padding, and inherently encrypts and validates. We will also monitor TLS-PSK standardisation and implementation as a replacement of this custom AES encryption protocol in the future. We will plan to support backward compatibility with configurable modes CBC/GCM/TLS-PSK, but the recommended most secure mode will always be the default.