You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: index.bs
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -154,12 +154,12 @@ One of the most recommended modes of operation for AES is AES-CTR (AES in Counte
154
154
155
155
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.
156
156
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]].
158
158
159
159
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.
160
160
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.
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
196
196
It is important to note that keys with 256 bits length are considered secure against brute-force attacks even in a post-quantum scenario.
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.
200
200
201
201
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.
202
202
203
203
## Key exchange ## {#key-exchange}
204
204
The main objective of key exchange is to establish a shared secret between two parties over an insecure channel.
205
205
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.
206
206
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.
208
208
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]].
209
209
210
210
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
282
282
The main objective of a MAC is to provide data authenticity and integrity.
283
283
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.
284
284
285
-
The current reccommended MACs are HMAC, KMAC256 and Keyed BLAKE2.
285
+
The current recommended MACs are HMAC, KMAC256 and Keyed BLAKE2.
286
286
287
287
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.
288
288
@@ -292,7 +292,7 @@ There exist other MACs that are not standardized, Keyed BLAKE2b-256 and Keyed BL
292
292
293
293
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.
294
294
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.
296
296
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.
297
297
In general, MACs with 64 bits tag length are considered weak and not recommended for secure applications.
298
298
@@ -308,7 +308,7 @@ BLAKE2 also supports a keyed mode, which can be used as a KDF. Keyed BLAKE2b-256
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.
310
310
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.
312
312
313
313
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.
0 commit comments