[ http://jira.jboss.com/jira/browse/JGRP-22?page=history ]
Bela Ban resolved JGRP-22:
--------------------------
Resolution: Done
Fix Version: 2.2.8
(was: 2.2.9)
> Enhance the ENCRYPT or the ENCRYPT1_4 protocol
> -----------------------------------------------
>
> Key: JGRP-22
> URL: http://jira.jboss.com/jira/browse/JGRP-22
> Project: JGroups
> Type: Feature Request
> Versions: 2.2.8
> Reporter: Roland R?z
> Assignee: Bela Ban
> Fix For: 2.2.8
>
>
> The ENCRYPT and the ENCRYPT1_4 protocol have both some weaknesses and missing
> features. There is no strong protection against replay attacks, everybody can
> join when using an asymmetric algorithm and messages encrypted with a wrong
> key are not discarded.
> The difference between the ENCRYPT1_4 and the ENCRYPT protocol is that
> ENCRYPT1_4 provides no support for a configured symmetric key (ENCRYPT1_4
> generates and distributes a symmetric key). ENCRYPT provides a feature for a
> symmetric key configured in a keystore. In this case the asymmetric key
> generation is not used. The symmetric and asymmetric features cannot be
> combined.
> The asymmetric and symmetric part of the ENCRYPT protocol could be separated
> in two protocols and some features could be enhanced.
> The ultimate solution could look like that:
> The lowest (e.g. CRYPTO_SYM) would be responsible for encryption/decryption
> and could be used in any layer below the symmetric cryptography (e.g.
> CRYPTO_KEY_DIST) protocol. The key for CRYPTO_SYM comes either from a file
> (e.g. as keystore or just as binary stuff protected with file system rights)
> or from a file AND from CRYPTO_SYM. In the second mode (CRYPTO_SYM +
> CRYPTO_KEY_DIST) CRYPTO_SYM needs to encrypt/decrypt the messages from
> CRYPTO_KEY_DIST with the simple file or keystore based key or does not need
> to be encrypted (to solve bootstrap, synchronization). The type of the
> message (is from CRYPTO_KEY_DIST or not) has to be sent along the wire.
> CRYPTO_KEY_DIST must be above the "reliability" layers and the master creates
> for each change in the view a new key. This key is sent down to the
> CRYPTO_SYM layer where it is combined with the symmetric key. CRYPTO_KEY_DIST
> should verify a new member with a challenge response procedure (e.g. based on
> the same symmetric key as CRYPTO_SYM)
> A nice feature of the CRYPTO_SYM would be to hash the messages and encrypt
> the hash along with the message so that the message can be verified.
> Currently the layers above ENCRYPT have to handle and discard corrupt
> messages.
> CRYPTO_SYM could be run without CRYPTO_KEY_DIST but the usage of both
> together would protect JGroups from replay attacks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
