AES and DES are symmetric key encryption mechanisms.

DES and AES are examples of block-based ciphering mechanisms.

The DES (Data Encryption Standard) for symmetric encryption is obsolete (it is not used) respect to the AES (Advanced Encryption Standard).

It is not possible to use the AES algorithm for digital signature.

In cryptography, the “confusion” principle is the one that provokes that a small change in the key achieves a big change in the ciphered text.

In cryptography, the “diffusion” principle is the one that achieves that with a small change in the clear text, a big change in the ciphered text will happen (plain text vs. cipher text independence).

SubBytes, ShiftRows and MixColumns are examples of permutations of the RSA algorithm for symmetric encryption.

ShiftRows, MixColumns and AddRoundKey are examples of permutations of the DES algorithm for symmetric encryption.

Diffie-Hellman allows sharing a secret key through the communication channel in a secure manner.

In Diffie-Hellman, two machines A and B manage to share a secret key by interchanging the values αa (sent by A) and αb (sent by B), being a∈G and αa∈G, and also b∈G and αb∈G, where G is a multiplicative finite group with a generator α∈G known by A and B. On the other hand, a and b are only known by A and B, respectively.

In Diffie-Hellman, two machines A and B manage to share a secret key by interchanging the values αa (sent by A) and αb (sent by B), being a∈G and αa∈G, and also b∈G and αb∈G, where G is a multiplicative finite group with a generator α∈G known by A and B. On the other hand, a and b are known by both A and B, but not by the rest of machines.

In “asymmetric encryption”, the recipient’s private key is used to encrypt a message.

It is not useful ciphering with symmetric key and sending that key through a public key mechanism.

An electronic signature is generated with the public part of the asymmetric key of the signer.

In security, Hash algorithms are used to interchange symmetric keys.

In asymmetric encryption, the secret part of the key may be deduced from the public part of the key.

In symmetric encryption, the public part of the key may be encrypted with the secret part.

In RSA, the e value of the public key must be coprime with the value of Φ(n).

In RSA, the secret part of the key is calculated directly from the two values of the public part, e and n.

In the ElGamal mechanism for asymmetric encryption, we need the secret key in order to calculate the public key.

In the ElGamal mechanism for asymmetric encryption, the secret key Ks is calculated as Ks = αKp, being Kp the public key, and α a known number.

In the ElGamal mechanism for asymmetric encryption, the public key Kp is calculated as Kp = αKs, being Ks the secret key, and α a known number.

In the ElGamal mechanism for asymmetric encryption, to encrypt m we should calculate c=m*(αa)v mod g, where v is a random number chosen by the sender, which is not sent.

In the ElGamal asymmetric encryption mechanism, to encrypt m we should calculate c=m*(αa)v mod g, where v is a random number chosen by the sender, that is also sent.

Apart from other responsibilities, a Registration Authority (RA) verifies the information about the user to whom a certificate is to be given.

In PKI, if we compare OCSP with SCVP, we can say that OCSP needs more complex clients.

OCSP (Online Certificate Status Protocol) builds the certification path of a certificate in order to validate it.

SCVP (Server-Based Certificate Validation Protocol) is better that OCSP (Online Certificate Status Protocol) in that it allows clients not to worry about constructing the certification path.

In SCVP (Server-Based Certificate Validation Protocol), the clients’ software needs to implement more tasks than in OCSP (Online Certificate Status Protocol).

SCVP (Server-Based Certificate Validation Protocol) builds the certification path of a certificate in order to validate it.

To generate a trusted time stamp, a Time Stamping Authority uses Hash and PKI technology.

In order to confirm that the time is correct, a Time Stamping Authority needs to keep a copy of the document to which a time stamp is assigned.

The PKI distributed trust model does not use Certification Authorities.

In a Plain trust model, the certificate of the CA is self-signed.

In a Plain trust model, the certificate of the CA is self-signed.

In the case of a hierarchical trust model, a X.509 certificate includes the signature of all the certification authorities of the tree.

In PKI, a Plain trust model is as a Hierarchical one, but the Plain only has the root CA and a unique level of CAs.

The PKI trust list model is controlled by the user.

Without adding hybrid mechanisms, a user of a CA following the hierarchical model will not trust in a certificate coming from another CA following the plain model.

The Bridge trust model only works with PKIs using the hierarchical model.

The PKI bridge certification trust model is more efficient than the cross-certification one with respect to the number of needed certificates.

The Bridge trust model implies adding a new Certification Authority.

A X.509 certificate includes the signature of the owner of the certificate.

A X.509 certificate includes the public key of its owner.

A digital certificate includes the signature of the Certification Authority issuing that certificate.

ASN.1 is a protocol to interchange X.509 certificates.

ASN.1 is a data representation language used to formalize XML documents.

ASN.1 is a data representation language used to formalize X.509 certificates that has been standardized by the IETF (Internet standard).

ASN.1, standardized by ISO, is the data representation language used to formalize X.509 certificates.

PKCS#7 (Public-Key Cryptography Standards 7) specifies how to send encrypted documents and their signatures. Some of its concepts are applied in the security of the e-mail.

In a PKCS#7 message of type enveloped data, it is possible to sign over a hash or digest of the message.

In a PKCS#7 message of type enveloped data, the signature algorithm should be RSA.

In a PKCS#7 message of type signed data, it is not possible to sign over a hash or digest of the message.

In a PKCS#7 message, the symmetric key is not sent, since it is supposed to be transfer by non-electronic means.

There are PKCS#7 messages that define how to send a public key with a symmetric key.

In PKCS#7, signedAndEnvelopedData is just adding signedData to EnvelopedData.

PKCS#7 (Cryptographic Message Syntax) is one of the few (less than 20) PKCS rules.

PKCS#7 (Cryptographic Message Syntax) is one of hundreds of PKCS rules.

The security of HTTPS may be achieved adding security to TCP.

There is a new version of the TLS protocol (TLSv1.3) that reduces the number of steps in the handshake phase.

Version 1.3 of the TLS protocol (TLSv1.3) increases, with respect to the previous version, the number of phases in the initial handshake in order to improve the security level.

In TLSv1.3, certificates are only mandatory for the server.

In TLSv1.3 it is mandatory that the server presents a certificate, while the client’s certificate is not always mandatory.

In TLSv1.3, certificates are no longer used because the symmetric key is encrypted with Diffie-Hellman algorithms.

TLSv1.3 supports 5 cipher suites. TLS_AES_128_GCM_SHA256 is an example of suite.

TLSv1.3 supports 5 cipher suites. All of them are based on AES.

TLSv1.3 specifies a handshake protocol phase that includes authentication and 'cipher suite' negotiation.

In TLSv1.3, the symmetric key is encrypted with Diffie-Hellman algorithms.

In TLSv1.3, 'cipher suite' negotiation is part of the handshake protocol.

At least two of the 5 cipher suites in TLSv1.3 support stream encryption (not only block encryption).

TLSv1.3 specifies a handshake protocol phase that includes authentication, but 'cipher suite' negotiation is left out of the protocol.

QUIC ('A UDP-Based Multiplexed and Secure Transport') does not provide its own security mechanism. Therefore, we need to add a security mechanism over it.

In order to have a secure protocol, we do not need to add a TLSv1.3 layer to a QUIC ('A UDP-Based Multiplexed and Secure Transport') implementation.

QUIC standardizes how to combine it with any application protocol.

One of the objectives in the design of QUIC has been to reduce the latency in the connection establishment phase.

A limitation of QUIC (“A UDP-Based Multiplexed and Secure Transport”) is that the security has to be added on top (for example, by adding TLSv1.3).

TLSv1.3 functionalities are included in QUIC (“A UDP-Based Multiplexed and Secure Transport”).

HTTP/3 is “HTTP over QUIC”. Therefore, TCP is not used.

HTTP/3 is “HTTP over QUIC”. The problem is that the new features from HTTP/2 are lost.

S/MIME is MIME sent over PKCS#7 (enveloped data type).

XML Encryption is a W3C Recommendation, but XML Signature it is not.

XML Encryption always provides non repudiation.

The encrypted content obtained with XML Encryption is always included in the document resulting from the encryption process.

The encrypted content obtained with XML Encryption may be referenced from the XML document itself, instead of being included in the document resulting from the encryption process.

If ciphered data are included in XML Encryption, they are inside the element CipherValue, coding in base64 the sequence of encrypted octets.

A detached signature in XML Signature means that the signature element may be, optionally, kept out of the signed XML document.

A detached signature in XML Signature means that the signature element is outside the signed XML document.

In XML Signature, in the case of a detached signature, the signature element is at the root of the signed XML element.

In XML Signature, in the detached case, the signature element is not in the same XML document that it is signed.

In a detached XML signature, the signed document is referenced from the Reference element, which is part of the Signature element.

In XML Signature, the signature algorithm that generates the SignatureValue element is applied to the canonicalization of the SignedInfo element of the Signature element.

In XML Signature, both in the enveloped and in the enveloping cases, the signature element is included in the signed XML document.

In XML Signature, if an element signature is part of another element, this means that the signature is enveloping.

In XML Signature, the signature algorithm that generates the SignatureValue element is directly applied on the Digest of the XML document.

In XML Signature, the signature algorithm that generates the SignatureValue element is applied to the SignedInfo element (its canonicalization), which includes more elements than just the Digest of the XML document to sign.

In XML Signature, the signature algorithm that generates the SignatureValue element is applied to the canonicalization of the SignedInfo element, which includes the canonicalization method, the signature method, the URI and the Digest.

In XML Signature, the Digest element is the data on which the signature algorithm is applied.

In XML Signature, the Digest of the document to sign is included in the element SignedInfo.

In XML Signature, the Digest of the document to sign is included in the element SignedInfo only when the signature is enveloped or enveloping.

It is not possible to express a SAML token in XML.

SAML Assertions” are data structures represented in XML.

In SAML, users identify themselves in front of a Service Provider that, afterwards, communicates with an Identity Provider in the name of the user.

In SAML, the user is identified in front of an Identity Provider.

In SAML, the user must initially connect to an Identity Provider before accessing the Service Provider.

In SAML, the Identity Provider and the Service Provider always communicate directly between them when a user wants access to a resource in the Service Provider.

In SAML, when a user wants to Access to a resource in a Service Provider, the Identity Provider and the Service Provider communicate through the user.

A browser implementing SAML will need to transfer information between an Identity provider and a Service provider. For this purpose, it will use the POST method when using HTTP.

The OAuth 2.0 protocol is fully compatible with its previous version (OAuth 1.0 protocol).

The OAuth 2.0 protocol is implemented over HTTP, and a response could include JSON information or XML data in its body.

OAuth is an authorization protocol.

In OAuth 2.0, the “Authorization code” is one type of “Authorization grant”.

In OAuth 2.0, the “redirect_uri” is part of the “Access token request”.

With the OAuth 2.0 protocol, the password of the user is never shared with the application.

The OAuth 2.0 protocol protects user’s password by encrypting it when shared.

tocol protects user’s password by encrypting it when shared.

The OAuth 2.0 protocol shares the password of the users with the application that acts on their name, but this is done in a secure way so no one else may have access to the password.

The OAuth 2.0 protocol does not normally share the password of the users with the application that acts on their name. When needed, this is done in encrypted mode.

Resource Owner, Resource Server and Client Application are examples of the roles defined by OAuth 2.0.

Two of the features of the OAuth 2.0 protocol are that allows users to approve an application to act on their behalf and that the password is not shared with the application.

In OAuth 2.0, the “scope” is part of the “Authorization response”.

A token endpoint is used by the client to exchange an authorization grant for an access token, typically with client authentication.

The body of an access token response in OAuth 2.0 may include a JSON string.

OpenID Connect is a simple layer to handle identity on top of OAuth 2.0.

OpenID Connect provides authorization, so it is very useful to use in combination with OAuth 2.0, which provides authentication.

JSON Web Tokens (JWT) are intended as a simplification of XML.

A JWT structure is a sequence of ASCII characters.

In JSON Web Tokens (JWT), information such as the “Signing/decrypting algorithm” is inside the Header, while the claims are part of the Payload.

The JWT structure is Base64Url encoded.

The Encrypted JWT standard recommends content encryption algorithms, but no key encryption algorithms.

In the Encrypted JWT there is no protected header.

As for XML, JSON has its own “JSON Web Signature” and “JSON Web Encryption”, also standardized by W3C.

A JWT structure contains a Header, the Payload and a Signature. All three are mandatory.

An Encrypted JWT (JWE) contains a Protected header, an Encrypted key (symmetric), an Initialization vector, the Encrypted data (ciphertext) and an Authentication tag. The vector and the tag are optional, while the rest are mandatory.

Privacy controls that reduce Privacy Identifiable Information (PII) are examples of Privacy Enhancing Technologies (PETs).

Privacy Enhancing Technologies (PETs) help controlling access to Privacy Identifiable Information (PII).

Personally Identifiable Information (PII) is the one that can be freely distributed, since it does not affect the privacy of their owners.

The name of a person may be considered Personally Identifiable Information (PII), while their identity card number is not considered PII.

Health data are not considered Personally Identifiable Information (PII), so they should not be protected.

Anonymization and pseudonymization tools are examples of PETs (Privacy Enhancing Technologies).

Anonymization is an example of PET (Privacy Enhancing Technology), while pseudonymization is not.

The PDP (Policy Decision Point) needs information from the PAP (Policy Administration Point) and the PIP (Policy Information Point) in order to take an access decision.

The PEP (Policy Enforcement Point) is the one that controls the access to the resources, while the PDP (Policy Decision Point) is the one who takes the decision based on the policies and other information.

In access control systems, the PEP (Policy Enforcement Point) does not always need a PDP (Policy Decision Point).

Users request access to the PEP (Policy Enforcement Point), but the module that works with the policies to allow or deny access is the PDP (Policy Decision Point).

The Discretionary Access Control is based on the use of security labels (levels and categories).

The Mandatory Access Control is based on the use of security labels (levels and categories).

Security labels are used in MAC (Mandatory Access Control), but not in DAC (Discretionary Access Control).

RBAC means Record Based Access Control, and, as its name indicates, is based in “records” with information of the users.

ABAC is an Access Control mechanism based on attributes.

XACML (eXtensible Access Control Markup Language) is a W3C standard.

XACML defines elements such as Rule, Policy and PolicySet.

XACML is useful for the RBAC model, but not for the ABAC one.

XACML is a XML-based language used to represent licenses.

XACML is a language to define privacy policies using rules.

XACML is a standard that allows expressing rules for access control.

With XACML we are able to specify the rules that control the access to a specific resource.

XACML is software that allows to control access to the data.

In XACML, the Rule Combining Algorithm allows to decide how to combine encryption mechanisms.