[jira] [Resolved] (CRYPTO-81) improve factory api for constructing Random & Cipher

["Xianda Ke (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CRYPTO-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xianda Ke resolved CRYPTO-81.
-----------------------------
    Resolution: Fixed

Since it is already fixed in CRYPTO-74, combined with some of the ideas in CRYPTO-81, so close this jira.


> improve factory api for constructing Random & Cipher
> ----------------------------------------------------
>
>                 Key: CRYPTO-81
>                 URL: https://issues.apache.org/jira/browse/CRYPTO-81
>             Project: Commons Crypto
>          Issue Type: Bug
>            Reporter: Xianda Ke
>            Assignee: Xianda Ke
>
> currently, the client code to construct a CryptoRandom or CryptoCipher looks like this:
> {code}
> // code snippet (a)
> Properties props = new Properties();
> props.setProperty(
>      ConfigurationKeys.COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY,
>                 OpensslCryptoRandom.class.getName());
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
> {code}
> or using configuration file, it looks like :
> {code}
> # config file
> secure.random.classes="org.apache.commons.crypto.random.OpensslCryptoRandom"
> {code}
> {code}
> // code snippet (b)
> {
>     Properties props = loadMyApplicationConfig();
>     // ...
> }
>  
> {
>     // bussiness logic ...
>     CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
>     // ...
>     CryptoCipher cipher = CryptoCipherFactory.getInstance(transform, props);
> }
> {code}
> disadvantages:
> 1. if client user just want use openssl engine,  trivial stuff in code snippet (a). it looks annoying.
> 2. Client user has to use the long long config key string such as  "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY" or full name of classes
>  Client user has to read source to  learn how to config the properties. 
> 3. the implementation classes such as JavaCryptoRandom,  OsCryptoRandom and JavaCryptoRandom are public.
> it would be hard to change library implementation in future.
> if we just *use a enum (RandomProvider or CryptCipherProvider)*
> {code}
> // code snippet (c)
> // client code looks simple and elegant now:
> //RandomProvider.OS or RandomProvider.JAVA
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(RandomProvider.OPENSSL);
> {code}
> still, client user can use configuration file
> {code}
> # config file
> RandomProvider="OPENSSL"
> CryptCipherProvider="JCE"
> {code}
> {code}
> // code snippet 
> {
>     Properties props = loadMyApplicationConfig();
>     RandomProvider randProvider = RandomProvider.valueOf(props.getProperty(p1));
>     CryptoProvider cryptoRrovider =RandomProvider.valueOf(props.getProperty(p1));
> }
> {
>     // bussiness logic ...
>     CryptoRandom random = CryptoRandomFactory.getCryptoRandom(randProvider);
>     // ...
>     CryptoCipher cipher = CryptoCipherFactory.getInstance(transform, cryptoRrovider);
> }
> {code}
> advantages:
> 1. Simpler API.  snippet (c) is simpler than snippet (a).  
> 2. Modern IDE will hint that CryptoRandomFactory.getCryptoRandom()  need a enum type (RandomProvider). client user do NOT have to search the long  key string such as "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY". Modern IDE will tell client user how to config
> 3. we don't have to expose the implementation classes as public



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)