commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xianda Ke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CRYPTO-81) improve factory api for constructing Random & Cipher
Date Fri, 17 Jun 2016 02:27:05 GMT

    [ https://issues.apache.org/jira/browse/CRYPTO-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335239#comment-15335239
] 

Xianda Ke commented on CRYPTO-81:
---------------------------------

Thanks [~sebb@apache.org] for your comments.

Crypto is mainly intended for a high performance implementation using Openssl engine which
is well optimized with hardware instructions acceleration. Currently, JCE's performance falls
far behind Openssl.

So far as I know, Crypto is not intended for a scalable framework like JCE which supports
3rd implementations.
Take transformation for instance, JCE use string parameter ("AES/CTR/NoPadding") to support
any 3rd implementations. But Crypto code just use enum CipherTransformation. 


> 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)

Mime
View raw message