[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky edited comment on JGRP-2274 at 8/28/19 7:52 PM: -------------------------------------------------------------- [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP/TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? was (Author: nsawadsky): [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP or TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? -- This message was sent by Atlassian Jira (v7.13.5#713005)