[xwiki-devs] [Proposal] Crypto API - Expose Bouncy Castle, JCA or not ?
Hi devs, In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API. In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities: 1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API. 2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC. 3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well. I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world. WDYT ? -- Denis Gervalle SOFTEC sa - CEO
On Thu, Oct 31, 2013 at 2:01 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API.
In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities:
1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API.
2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC.
3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well.
I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world.
WDYT ?
I also prefer 2) and 3). I will let others decide if BC is standard enough in practice to go with 3) but I'm clearly not against it, we are strongly tied to slf4j for example and it seems to be that BC is quite used in Java world and clean and easy enough to extend to never really be stuck.
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Same as Thomas. I'm fine with either 2) or 3) Thanks, Marius On Thu, Oct 31, 2013 at 3:21 PM, Thomas Mortagne <[email protected]> wrote:
On Thu, Oct 31, 2013 at 2:01 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API.
In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities:
1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API.
2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC.
3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well.
I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world.
WDYT ?
I also prefer 2) and 3). I will let others decide if BC is standard enough in practice to go with 3) but I'm clearly not against it, we are strongly tied to slf4j for example and it seems to be that BC is quite used in Java world and clean and easy enough to extend to never really be stuck.
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 31 Oct 2013, at 14:01, Denis Gervalle <[email protected]> wrote:
Hi devs,
In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API.
In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities:
1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API.
2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC.
3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well.
I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world.
WDYT ?
JCA is a spec so it’s stable and the standard. +1 for JCA. BTW there’s also Apache Shiro which might be interesting to look at http://shiro.apache.org/ Thanks -Vincent
On 10/31/2013 09:01 AM, Denis Gervalle wrote:
Hi devs,
In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API.
In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities:
1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API.
2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC.
3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well.
I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world.
WDYT ?
BouncyCastle is indeed a de-facto standard for cryptography, so +1 for 3). -- Sergiu Dumitriu http://purl.org/net/sergiu
participants (5)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol