[jboss-jira] [JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

[Nick Sawadsky (Jira)]

    [ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773220#comment-13773220 ] 

Nick Sawadsky edited comment on JGRP-2274 at 8/20/19 4:39 PM:
--------------------------------------------------------------

[~belaban] I'm afraid it's not the case. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm.

Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encryption-with-aes-in-java-and-android-part-2-b3b80e99ad36] has a good description of the steps.

Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encryption-with-aes-in-java-7616beaaade9] describes how to go about implementing this type of encryption in Java.

ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt.


was (Author: nsawadsky):
[~belaban] I'm afraid not. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm.

Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encryption-with-aes-in-java-and-android-part-2-b3b80e99ad36] has a good description of the steps.

Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encryption-with-aes-in-java-7616beaaade9] describes how to go about implementing this type of encryption in Java.

ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt.

> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
>                 Key: JGRP-2274
>                 URL: https://issues.jboss.org/browse/JGRP-2274
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)