Skip to content

Commit cf6e98f

Browse files
authored
Correct spelling of 'recommended'
1 parent ce97732 commit cf6e98f

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

index.bs

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -154,12 +154,12 @@ One of the most recommended modes of operation for AES is AES-CTR (AES in Counte
154154

155155
Since the length of the plaintext is not necessarly multiple of the block length,padding techniques are used to add extra data to the plaintext to ensure that its size aligns with the block size required by block cipher algorithms. Padding is necessary because block ciphers operate on fixed-size blocks of data, and if the plaintext does not align with these blocks, it cannot be processed correctly.
156156
However, it is important to note that padding can introduce vulnerabilities if not implemented correctly according to the specs of the algorithm.
157-
Two reccommended padding schemes are PKCS#7 standardized in [[RFC5652]] and Bit padding standardized in [[ISO-IEC-9797-1]].
157+
Two recommended padding schemes are PKCS#7 standardized in [[RFC5652]] and Bit padding standardized in [[ISO-IEC-9797-1]].
158158

159159
Note: Symmetric encryption alone provides just confidentiality, but does not provide data authenticity or integrity. Indeed, an attacker may intercept and modify the ciphertext without detection, potentially influencing the decrypted result. Therefore, the only use of symmetric encryption algorithms with no authentication mechanism is generally discouraged and it is preferable to use cryptographic mechanisms specifically designed to provide also authenticity and integrity.
160160

161-
To provide confidentiality with authenticity it is reccommended the usage of a combination between symmetric encryption (providing confidentiality) and MACs (providiina authenticity and integrity).
162-
It is reccommended the usage of AES-CTR and HMAC (Encrypt-then-MAC) or the usage of a single authenticated encryption with associated data (AEAD) scheme such as AES-GCM.
161+
To provide confidentiality with authenticity it is recommended the usage of a combination between symmetric encryption (providing confidentiality) and MACs (providiina authenticity and integrity).
162+
It is recommended the usage of AES-CTR and HMAC (Encrypt-then-MAC) or the usage of a single authenticated encryption with associated data (AEAD) scheme such as AES-GCM.
163163

164164
### Authenticated encryption ### {#authenticated-encryption}
165165
Authenticated encryption with associated data (AEAD) schemes provide confidentiality, integrity, and authenticity in a single operation. They combine encryption and authentication mechanisms to ensure that the data remains confidential while also verifying its integrity and authenticity.
@@ -196,15 +196,15 @@ Some algorithms are designed to use keys of fixed length (256 bits in the case o
196196
It is important to note that keys with 256 bits length are considered secure against brute-force attacks even in a post-quantum scenario.
197197

198198
## Asymmetric encryption ## {#asymmetric-encryption}
199-
In PKCS#1 v2.2 [[RFC8017]] two encryption schemes constructed by RSA algorithm are specified: RSAES-OAEP and RSAES-PKCS1-v1_5. RSAES-OAEP is required to be supported for new applications. Instead, RSAES-PKCS1-v1_5 is quite still used, its use is not reccommended as it has to be intended for legacy applications only, and it is included only for compatibility with already existing applications.
199+
In PKCS#1 v2.2 [[RFC8017]] two encryption schemes constructed by RSA algorithm are specified: RSAES-OAEP and RSAES-PKCS1-v1_5. RSAES-OAEP is required to be supported for new applications. Instead, RSAES-PKCS1-v1_5 is quite still used, its use is not recommended as it has to be intended for legacy applications only, and it is included only for compatibility with already existing applications.
200200

201201
Note: The usage of asymmetric encryption is generally discouraged for data encryption, and it is preferable to use symmetric encryption to encrypt data with an asymmetric algorithm to exchange the symmetric key.
202202

203203
## Key exchange ## {#key-exchange}
204204
The main objective of key exchange is to establish a shared secret between two parties over an insecure channel.
205205
The parties involved are provided with a pair of keys: a public key, which can be shared with anyone, and a private key, which must be kept secret. The public key of each party is published or exchanged, while the private key remains confidential. The shared secret is derived using the private key of one party and the public key of the other party. This process ensures that only the two parties involved can compute the shared secret, as it requires knowledge of the private key.
206206

207-
The current reccommended key exchange algorithms are ECDH (Elliptic Curve Diffie-Hellman) and the post-quantum key exchange schemes ML-KEM amd HQC.
207+
The current recommended key exchange algorithms are ECDH (Elliptic Curve Diffie-Hellman) and the post-quantum key exchange schemes ML-KEM amd HQC.
208208
The most used today is ECDH, descrived in [[RFC6090]]. The main aspect of ECDH is the choice of the elliptic curve used and the most widely used and recommended curves are the NIST curves P-256 (with 128 security bits), P-384, P-521 (with 256 security bits) also noted as Secp256r1, Secp384r1, Secp521r1 respectively and standardized in [[FIPS-186-5]].
209209

210210
Other common curves most used are the Montgommery curves Curve2559 and Curve448. ECDH with Curve2559 is named X25519 and ECDH with Curve448 is named X448. They are not a standard by NIST, but are widely used and recommended for their security and performance. They are defined in [[RFC7748]]. The difference betweem them is the security level and performance, with X25519 being faster and more efficient (128 security bits), while X448 offers a higher security level (224 security bits).
@@ -282,7 +282,7 @@ Another selected post-quantum digital signature scheme is Falcon, which is a lat
282282
The main objective of a MAC is to provide data authenticity and integrity.
283283
A MAC is a short piece of information, typically a fixed-size string of bytes, that is generated using a secret key and a message. The MAC is appended to the message and sent to the recipient, who can then use the same secret key to generate a MAC for the received message and compare it to the received MAC. If the two MACs match, it indicates that the message has not been altered and comes from a legitimate sender.
284284

285-
The current reccommended MACs are HMAC, KMAC256 and Keyed BLAKE2.
285+
The current recommended MACs are HMAC, KMAC256 and Keyed BLAKE2.
286286

287287
One of the most used MAC is HMAC (Hash-based Message Authentication Code), which is standardized in [[FIPS-198-1]] and [[RFC2104]]. HMAC can be used with any underlying hash function, such as SHA-256 or SHA-512. It is widely used in various cryptographic protocols and applications, including TLS (Transport Layer Security) and IPsec (Internet Protocol Security), to ensure data authenticity and integrity.
288288

@@ -292,7 +292,7 @@ There exist other MACs that are not standardized, Keyed BLAKE2b-256 and Keyed BL
292292

293293
The length of the MAC tag is an important factor in determining the security of the MAC. Longer tags provide stronger security, as they increase the complexity of brute-force attacks (or birthday attacks). However, longer tags also require more computational resources for generation and verification processes. Therefore, it is essential to balance security and performance when selecting the length of the MAC tag.
294294
In general, the recommended tag length for MACs is at least 128 bits to provide adequate security against brute-force attacks, while 256 bits tag length provides a higher level of security for applications that require stronger protection.
295-
In general, it is always reccommended to use a hash function with digest at least 256 bits long to avoid collision attacks.
295+
In general, it is always recommended to use a hash function with digest at least 256 bits long to avoid collision attacks.
296296
For HMAC, the recommended tag length is at least 160 bits when using SHA-1 as the underlying hash function, and at least 256 bits when using SHA-256 or SHA-512. For KMAC256, the recommended tag length is at least 256 bits. For Keyed BLAKE2, the recommended tag length is at least 128 bits for Keyed BLAKE2b-256 and at least 256 bits for Keyed BLAKE2b-512.
297297
In general, MACs with 64 bits tag length are considered weak and not recommended for secure applications.
298298

@@ -308,7 +308,7 @@ BLAKE2 also supports a keyed mode, which can be used as a KDF. Keyed BLAKE2b-256
308308
### Password-based key derivation functions (PBKDFs) ### {#password-based-key-derivation-functions-pbkdfs}
309309
Password-based key derivation functions (PBKDFs) are cryptographic algorithms that derive one or more keys from a password or passphrase which tipycally have low entropy. They are designed to be computationally intensive and resistant to brute-force attacks, making it difficult for attackers to guess the password and derive the keys.
310310

311-
The most reccommended PBKDF is Argon2id, described in [[RFC9106]], which is a memory-hard function that provides strong security guarantees against various types of attacks. Argon2id is designed to be efficient in both software and hardware implementations and is widely used in password hashing and key derivation applications.
311+
The most recommended PBKDF is Argon2id, described in [[RFC9106]], which is a memory-hard function that provides strong security guarantees against various types of attacks. Argon2id is designed to be efficient in both software and hardware implementations and is widely used in password hashing and key derivation applications.
312312

313313
PBKDF2 is standardized in [[RFC8018]]. It is based on the HMAC construction and can be used with any underlying hash function, such as SHA-256 or SHA-512.
314314

0 commit comments

Comments
 (0)