[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky commented on JGRP-2274: ------------------------------------- [~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-encry...] 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-encry...] 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. -- This message was sent by Atlassian Jira (v7.12.1#712002)