Class CachingCryptoMaterialsManager

  • All Implemented Interfaces:

    public class CachingCryptoMaterialsManager
    extends Object
    implements CryptoMaterialsManager
    The CachingCryptoMaterialsManager wraps another CryptoMaterialsManager, and caches its results. This helps reduce the number of calls made to the underlying CryptoMaterialsManager and/or MasterKeyProvider, which may help reduce cost and/or improve performance. The CachingCryptoMaterialsManager helps enforce a number of usage limits on encrypt. Specifically, it limits the number of individual messages encrypted with a particular data key, and the number of plaintext bytes encrypted with the same data key. It also allows you to configure a maximum time-to-live for cache entries. Note that when performing streaming encryption operations, unless you set the stream size before writing any data using CryptoOutputStream.setMaxInputLength(long) or CryptoInputStream.setMaxInputLength(long), the size of the message will not be known, and to avoid exceeding byte use limits, caching will not be performed. By default, two different CachingCryptoMaterialsManagers will not share cached entries, even when using the same CryptoMaterialsCache. However, it's possible to make different CachingCryptoMaterialsManagers share the same cached entries by assigning a partition ID to them; all CachingCryptoMaterialsManagers with the same partition ID will share the same cached entries. Assigning partition IDs manually requires great care; if the backing CryptoMaterialsManagers are not equivalent, having entries cross over between them can result in problems such as encrypting messages to the wrong key, or accidentally bypassing access controls. For this reason we recommend not supplying a partition ID unless required for your use case.