This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "ESAPI Encryption"
From OWASP
(Added several possible enhancements.) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 4: | Line 4: | ||
== Possible Enhancements == | == Possible Enhancements == | ||
+ | * Potentially rename Seal and Unseal to better describe what they do | ||
+ | * seal() should include an HMAC or integrity check to ensure that the encrypted data has not been tampered with (see [http://cwe.mitre.org/data/definitions/649.html CWE-649]). (NOTE: By default, ESAPI crypto already ensures message authenticity and seal() uses that, so this likely would be redundant. -Kevin W. Wall) | ||
− | + | * The API should include support for key rotation; indicated key used for encryption of data | |
− | |||
− | * The API should include support for key rotation | ||
* The API should allow key management to be externalized, to allow developers to integrate their own key management strategies (such as a PKI). | * The API should allow key management to be externalized, to allow developers to integrate their own key management strategies (such as a PKI). | ||
* The documentation for each method should indicate whether it is designed to protect integrity, confidentiality, or both; and whether it is suitable for encrypting transient items (such as hidden form fields) or is designed for long-term storage. | * The documentation for each method should indicate whether it is designed to protect integrity, confidentiality, or both; and whether it is suitable for encrypting transient items (such as hidden form fields) or is designed for long-term storage. | ||
+ | |||
+ | * Get rid of JavaEncryptor as a singleton. It causes numerous problems and makes some things impossible if one wishes to only interact with it through the Encryptor interface level. | ||
+ | |||
+ | * Make it simpler to use different cipher algorithms or key sizes for symmetric encryption. This requires a major kludge today that is not at all thread safe without explicit locks. (It was so bad in fact, that the method to support this kludge was immediately deprecated!) | ||
+ | |||
+ | * Change sign() / validateSignature() so they can use persistent asymmetric keys and store public / private keys used with asymmetric crypto operations in a PKCS#12 or JKS key store. | ||
+ | |||
+ | * Create separate properties file for ESAPI crypto properties. Name it "ESAPI-Encryptor.properties" or something similar. (Google Issue #48.) | ||
+ | |||
+ | * Provide tamper-evident logging using cryptographic primitives as well as mechanism to verify that logs produced in such a manner have not been tampered with.1 | ||
+ | |||
+ | * Support for encrypting files. | ||
+ | |||
+ | * Support for format perserving encryption. (See [http://www.voltage.com/technology/Technology_FormatPreservingEncryption.htm] and [http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffsem/ffsem-spec.pdf]) |
Latest revision as of 05:33, 21 August 2011
Feature Overview
TODO
Possible Enhancements
- Potentially rename Seal and Unseal to better describe what they do
- seal() should include an HMAC or integrity check to ensure that the encrypted data has not been tampered with (see CWE-649). (NOTE: By default, ESAPI crypto already ensures message authenticity and seal() uses that, so this likely would be redundant. -Kevin W. Wall)
- The API should include support for key rotation; indicated key used for encryption of data
- The API should allow key management to be externalized, to allow developers to integrate their own key management strategies (such as a PKI).
- The documentation for each method should indicate whether it is designed to protect integrity, confidentiality, or both; and whether it is suitable for encrypting transient items (such as hidden form fields) or is designed for long-term storage.
- Get rid of JavaEncryptor as a singleton. It causes numerous problems and makes some things impossible if one wishes to only interact with it through the Encryptor interface level.
- Make it simpler to use different cipher algorithms or key sizes for symmetric encryption. This requires a major kludge today that is not at all thread safe without explicit locks. (It was so bad in fact, that the method to support this kludge was immediately deprecated!)
- Change sign() / validateSignature() so they can use persistent asymmetric keys and store public / private keys used with asymmetric crypto operations in a PKCS#12 or JKS key store.
- Create separate properties file for ESAPI crypto properties. Name it "ESAPI-Encryptor.properties" or something similar. (Google Issue #48.)
- Provide tamper-evident logging using cryptographic primitives as well as mechanism to verify that logs produced in such a manner have not been tampered with.1
- Support for encrypting files.