[ 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