Network security can be defined by three categories of assessment: authenticity, confidentiality, and integrity.

Authentication is achieved by adding extra information to a message, a digital signature or message digest. This identifies the origin of the data. Integrity checks could be done with checksums, CRCs, SHAs, etc.

Symmetric key encryption is generally faster in processing than asymmetric, but you have the problem of sharing the key.

Hashes

Secure hash algorithms offer a mechanism for both authentication and message integrity, by performing a one-way function on a message to produce a message 'digest'. No key is involved, unless you choose to do so by including a secret key in part of the message being processed. In this way the secure hash is different from, say, a block cipher. Any bit that changes in the message results in a completely different digest.

The SHA series of NSA algorithms include a constant (k) that have no special properties other than to be common knowledge and show that there is no hidden back door into the algorithm. An example might be the fractional component of a series of square roots of prime numbers.

Algorithm speed

http://www.cryptopp.com/benchmarks.html

HMACs can be computed quickly compared to many other encryption algorithms. Some commonly used cryptographic hashes and HMAC variations are listed here in order of decreasing speed:

	MD5
	HMAC(MD5)
	SHA-1
	HMAC(SHA-1)
	SHA-2
	HMAC(SHA-2)

PKI

A node that wants to receive encrypted data from 1+ senders must generate a related set: a public key, and private key. The public key is used to encrypt the data, so it is sent in the clear to the sources. The private key is kept and used to decrypt. This is an asymmetric system as two different keys are used and information can only go one way unless a separate set of keys is created for the other direction.

On Re-key

Remember that when a command is issued to change a key to a slave device, the response (command ACK) should remain encrypted with the old key so that the master can confirm receipt of the message. That means that the slave has to wait until the response is sent to change keys, and the master should wait until receiving the response to change keys. This is for the case that the same key is used for both directions of the comm channel.

However, it is probably recommended to use two different keys: outgoing encryption from one end and incoming decryption on the other end will be one key, while the opposite direction will be another key. Then you can more easily manage key updates probably, at the expense of having to manage two keys instead of one.

About TLS

Was originally based on SSL, although the latest (2018) SSL 3.0 is falling into disfavor with TLS 1.1+ recommended. Per, https://www.globalsign.com/en/blog/ssl-vs-tls-difference/ SSL and TLS are different and SSL is deprecated by the IETF with TLS taking over. The certificates are not differentiated.

The advantage of asymmetric cryptography (same two keys not required) is that the process of sharing encryption keys does not have to be secure, but the mathematical relationship between public and private keys means that much larger key sizes are required. The recommended minimum key length is 1024 bits, with 2048 bits preferred, but this is up to a thousand times more computationally intensive than symmetric keys of equivalent strength (e.g. a 2048-bit asymmetric key is approximately equivalent to a 112-bit symmetric key) and makes asymmetric encryption too slow for many purposes.

For this reason, TLS uses asymmetric cryptography for securely generating and exchanging a session key (symmetric). The session key is then used for encrypting the data transmitted by one party, and for decrypting the data received at the other end. Once the session is over, the session key is discarded.

How about digital signatures?

https://www.globalsign.com/en/blog/how-do-digital-signatures-work/

Trusted Platform Module (TPM)

The TCG (Trusted Computing Group) defines schemes for establishing trust in a platform that are based on identifying its hardware and software components. The Trusted Platform Module (TPM) provides methods for collecting and reporting these identities. A TPM used in a computer system reports on the hardware and software in a way that allows determination of expected behavior and, from that expectation, establishment of trust.

The TPM is not the trusted computing base of a system. Rather, a TPM is a component that allows an independent entity to determine if the TCB has been compromised. In some uses, the TPM can help prevent the system from starting if the TCB cannot be properly instantiated.

A TPM is implemented physically through either dedicated or borrowed resources. A single-chip solution: The TPM component has a processor, RAM, ROM, and Flash memory. The only interaction with these TPMs is through an (for example) LPC (Low Pin Count, low performance bus) bus or SPI.

Another reasonable implementation of a TPM is to have the code run on the host processor while the processor is in a special execution mode. For these TPMs, parts of system memory are partitioned by hardware so that the memory used by the TPM is not accessible by the host processor unless it is in this special mode. Further, when the host processor switches modes, it always begins execution at specific entry points.

Block Ciphers (like AES)

In the commonly used AES counter mode, you do block cipher operations on one 128-bit block at a time. The IV length is also 128 bits, while the key can be 128, 192, or 256. The IV is unique for each block and needs to be non-repeating and random. This ensures that distinct ciphertext is produced even from the same plaintext using the same key.

Counter mode is a little different than other modes because the IV is the part "encrypted" with the key. The resulting keystream is then XORed with the PT to create CT. Typically part of the IV (i.e. some of the 16 bytes) consists of a counter that is incremented with each processed block.

In this mode the IV is passed in the clear, used as the nonce, and the receiver increments it as a counter during decryption.

Nonce means "number used once".

AES-GCM Implementation Notes

The security of AES-GCM requires a unique initialization vector (IV) be used for each encrypted message. For a given key, it is critical to ensure that no IV is ever reused. MACsec meets this requirement by consecutively numbering each outgoing encrypted packet.

If keys are reused across multiple sessions, the packet counter associated with each key must be stored in nonvolatile memory. To prevent accidental reuse even in the case of interruption, the stored packet counter is incremented before use. A checkout process ensures that the next session always begins from a safe, unused packet number. Checkouts are made in large blocks; it is safe to skip ahead as needed by discarding unused packet numbers.

The checkout process consists of a read-increment-write cycle:

Read one copy of the stored key and packet number.
Integrity check: If invalid, try next copy of key. If none are valid, abort.
Increment the packet number by N.
Update checksum. Consecutively overwrite all stored copies of the key.
Ready to configure encryption module.

At the start of each session, the encryption module is configured by loading the key, initial packet number, and maximum packet number. If the encryption module reaches the maximum packet number for any reason, then it halts immediately. For short sessions, the increment size N is chosen to exceed the maximum length of that session. For longer sessions, the cycle is repeated as needed to extend the maximum packet number; N is chosen to allow sufficient time for uninterrupted operation.