Supported algorithmsCumulus4j uses very fast and highly secure algorithms by default. Thus, it is recommended that you just use the default settings. However, depending on your hardware or your personal taste, you might prefer a different configuration. For example, the default is to use TWOFISH with 256 bit key size. 256 bit key size is close to paranoia and you might choose to use only 128 bit instead in order to gain performance. With 256 bit keys, TWOFISH is more secure than AES. Furthermore, on ordinary hardware, Twofish is faster. However, on some CPUs or with 128 bit key size, AES might be slightly faster while providing approximately the same level of security. In the following, you'll find a list of all supported possibilities. However: Important: Changing the encryption settings can cause Cumulus4j to not work at all or - even worse - it might break security!!! Only change these settings, if you really know what you are doing! If you are unsure, stick with the "Recommended choices"! Symmetric encryptionSymmetric encryption is used to encrypt the data in your database. Since it requires secret keys, Cumulus4j provides a key store, which also uses symmetric encryption to protect your keys (in case you loose your key store - e.g. on a USB thumb drive - or someone steals it). Recommended choicesWhile there are many algorithms for encryption, block-mode, padding and MAC available to choose from, not all combinations of them work with Cumulus4j. Some others work, but make no sense; e.g. to combine an authenticating block-mode with a MAC means to have 2 (redundant!) message authentications which only slows down the system unnecessarily. Therefore, we provide a small choice here that might be suitable for you and preferred over the default settings:
"Encryption", "Mode" and "Padding" are usually concatenated to a string like "AES/GCM/NoPadding". The MAC is usually configured separately. In Persistence API, it is documented, how you configure this for the actual datastore and in Key store you'll see how you can apply different encryption/MAC settings to the key store. Block cipher enginesBlock ciphers are the most widely used encryption algorithms. They combine very high security with good performance.
Stream cipher enginesStream ciphers can be used instead of block ciphers. They are usually faster, but more susceptible to serious security problems if used incorrectly. However, we believe that Cumulus4j uses them correctly - e.g. by using long IVs - and you might give them a try, if high performance is essential to you (if you do benchmarks, please send them to us!). The main reason why we do not recommend them (yet), is that we cannot thoroughly test and investigate the multitude of supported algorithms. If you're willing to help us, please do! Here's what is supported at the moment:
Asymmetric encryptionAsymmetric encryption is used to protect the key exchange (of the keys that are used in the symmetric encryption). The key store is located on the client or on a separate key server (see Deployment scenarios), but the keys are needed on the application server in order to encrypt/decrypt the actual data. That means key transfers are necessary. In order to get the keys from the key store to the application server, usually an HTTPS connection protects them on their way through the open internet. However, in order to get the keys from one application server node to another node (in the typical cluster/cloud environment), the keys might be temporarily stored in a database. To protect the keys in these situations, asymmetric encryption is used. Every application server node generates a public/private-key-pair. Whenever it requires a secret key (for symmetric en-/decryption), it sends its public key together with the secret-key-request to the key-manager. The secret key is then encrypted with the public key and sent back. Only the original app-server-node can decrypt the secret key. An administrator who dumps the medium used for node-to-node-communication cannot make use of what he'll find there. RSA//OAEPWITHSHA1ANDMGF1PADDING is used by default. At the moment, there is no configuration setting to change this, yet. However, this will likely change soon. Block cipher operation modesBlock ciphers work - as the name implies - on a block of data (usually 64 or 128 bit). But usually there is more data to encrypt than just one block. That's why the block cipher engine is always combined with a mode of operation. The mode implements a secure way to encrypt (or decrypt) more than just one block. Cumulus4j supports the following modes:
PaddingSymmetricWhen encrypting data using a symmetric block-cipher, the input data usually does not match exactly the fixed block size. Therefore, with most block-cipher-modes, it is required that the last input block is filled up with additional bytes until it matches the required length.
AsymmetricIn public-key-cryptography, padding means to prepare a message for encryption using an elaborate algorithm. Originally, "padding" was nothing more than filling up the message with random bytes, but because this is not a secure form of padding, it is not used anymore. Modern padding algorithms are far more advanced in order to provide protection against many forms of attacks.
MACA Message authentication code (or MAC) is used to detect data manipulation or corruption. It is thus similar to a checksum, but in contrast to it, an attacker cannot simply modify a few more bits to produce the same checksum as the original message.
|
Documentation
AboutProject DocumentationBabelReleases
|
Deutsch