Return to Answer

1. ENC(M) || SignA(ENC(M))
   Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is not accomplished because the secret key is not signed together with the message. If the receiver uses a different key you'd get a different message after decryption, even though the signature over the ciphertext verifies. So it is NO for non-repudiation and YES for confidentiality and message integrity / authenticity.

2. ENC(M || SignA(M))
   This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. SignA(ENC(M))
   In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. ENC(M) || SignA(M)
   With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).

1. ENC(M) || SignA(ENC(M))
   Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is not accomplished because the secret key is not signed together with the message. If the receiver uses a different key you'd get a different message after decryption, even though the signature over the ciphertext verifies. So it is NO for non-repudiation and YES for confidentiality and message integrity / authenticity.

2. ENC(M || SignA(M))
   This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. SignA(ENC(M))
   In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. ENC(M) || SignA(M)
   With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).

Beware that generally these kind of questions are debated for "perfect" schemes, where E is perfect cipher and SignA cannot be broken. Furthermore, no other communication or actions are allowed other than the one specified.

I've already mentioned the oracle attacks and what could happen if the message was send afterwards. Those situations can and should be disregarded when answering the questions, even if they are definitely worth considering when implementing such a scheme in practice.

The reason is that you first need to get down the security of perfect schemes and can then on designing or analyzing systems based on the security claims. Then the next thing to do is to consider the practical systems. I'm however already very much rooted in practical application, so my brain starts to automatically insert warnings when looking at the schemes.

1. ENC(M) || SignA(ENC(M))
   Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is harder, because the signature is not over the actual message, you would have to store the secret key with the message after you've received it. They probably expect NO for non-repudiation and YES for confidentiality and message integrity / authenticity, but I think that's contentious.

2. ENC(M || SignA(M))
   This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. SignA(ENC(M))
   In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. ENC(M) || SignA(M)
   With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).

1. ENC(M) || SignA(ENC(M))
   Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is not accomplished because the secret key is not signed together with the message. If the receiver uses a different key you'd get a different message after decryption, even though the signature over the ciphertext verifies. So it is NO for non-repudiation and YES for confidentiality and message integrity / authenticity.

2. ENC(M || SignA(M))
   This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. SignA(ENC(M))
   In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. ENC(M) || SignA(M)
   With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).

1. Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is harder, because the signature is not over the actual message, you would have to store the secret key with the message after you've received it. They probably expect NO for non-repudiation and YES for confidentiality and message integrity / authenticity, but I think that's contentious.

2. This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

Syntax error, unclosed parentheses.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).

1. ENC(M) || SignA(ENC(M))
   Have confidentiality (from ENC), and authenticity from signature, but no integrity because i have the signature of ENC (so someone can use forgery on my signature) and non-reputation i don't think (but i m not sure).

Confidentiality is yes because of ENC, correct.

The other's are all linked to each other. They are present if the receiver only accepts signed messages and the verification is performed with the trusted public key of Alice. If a public key of an adversary is accepted then any random ciphertext can be created and signed.

Non-repudiation is harder, because the signature is not over the actual message, you would have to store the secret key with the message after you've received it. They probably expect NO for non-repudiation and YES for confidentiality and message integrity / authenticity, but I think that's contentious.

2. ENC(M || SignA(M))
   This have all property, because ENC give confidentiality, signature authenticity e non repudation and integrity because i have message and his signature for verify.

But yes, basically right. Note that if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down. This scheme is what we usually do.

3. SignA(ENC(M))
   In this schema i have confidentiality and authenticity , but no integrity. I m not sure about non-repudation.

The message is not send (!), so it is kept very confidential. You cannot even guess it, because the signature is over encrypted data. Integrity / authenticity are then of course nonsense. Non-repudiation is also not possible.

Unless somebody is able to get the original message and encrypt it again anyway. But usually only the given message are allowed (or you'd have issues with DoS and replay attacks and whatnot).

4. ENC(M) || SignA(M)
   With this schema i have confidentiality, integrity and authenticity. I have again doubt about non-repudation.

Wrong! You can guess the data and verify the signature. If it verifies, you've found the data. We commonly assume that the public key is known to all.

Once you've decrypted you have M, SignA(M) so there is your non-repudiation - and therefore integrity & authenticity.

Again: if the encryption scheme is vulnerable against e.g. plaintext / padding oracle attacks that the confidentiality breaks down (even more significantly for complex messages).